关于领域驱动设计与GIT的优势的个人理解_.NET_编程开发_程序员俱乐部

注：本文系作者原创，但可随意转载。

　　本文纯属个人观点，才疏学浅，不当之处，敬请斧正。

一、领域驱动设计

　　经常看到大家在讨论这个问题，百度一下也能看到很多相关博客。本身我并没有阅读过相关的书籍，只是百度过一些概念之类的，可能并没有真正地理解这个概念。

　　首先，领域驱动设计的核心是模型，在于建立一个领域模型。对于这个概念还是深表认同。我认为领域驱动设计的目的，本身即是为了便于理解，加快开发。领域模型即是对客观事实进行建模，而不是基于抽象，那么所建立的模型通俗易读，阅读代码的人一看就知道是什么意思。

　　举个例子：

　　 假设现在要做一个公司的内部人力资源管理系统，那么我们对系统进行简单地建模。

class="code_img_closed" src="/Upload/Images/2015033113/0015B68B3C38AA5B.gif" alt="" />logs_code_hide('bb945e90-931a-407a-9798-1e7984abdf69',event)" src="/Upload/Images/2015033113/2B1B950FA3DF188F.gif" alt="" />

 1 public class Company
 2 {
 3     public int CompanyId {get;set;}
 4     public string CompanyName {get;set;}
 5     public List<Department> Departments {get;set;}
 6     public string Address {get;set;}
 7     public string Contact {get;set;}
 8     public string Phone {get;set;}
 9     ...
10 }

 1 public class Department
 2 {
 3     public int DepartmentId {get;set;}
 4     public string DepartmentName {get;set;}
 5     public int CompanyId {get;set;}
 6     public virtual Company Company {get;set;}
 7     public int ManagerId {get;set;}
 8     public virtual Employee Manager {get;set;}
 9     public List<Employee> Employees {get;set;}
10     ...
11 }

1 public class Employee
2 {
3     public int EmployeeId {get;set;}
4     public string EmployeeName {get;set;}
5     public int Age {get;set;}
6     public string Gender {get;set;}
7     ....
8 }

　　很容易可以得出这样三个类，只需要把他们所拥有的属性按照客观事实写进去就可以，读代码的人也很容易GET到写代码的人的点。实际上建模也即是对数据库的设计，结合EF的CODE FIRST功能，可以直接在MSSQL中建立三张对应这三个类的表。在系统的使用过程中，大部分也是对表中数据简单的增删查改，可以直接通过领域模型来操作数据。这样大大提高了开发速度。

　　但我认为像这样建模仅适用于对真实世界进行建模，业务不是十分复杂的情形。如果我们提取出了领域模型，但是在实际使用的时候总是需要在领域模型，DTO, ViewModel之间转换来转换去，那么程序的结构实际上已经变成了事务脚本的模式，模型间的转换反倒加重了阅读和写代码的负担。

　　再举个例子：

　　假设现在做一个类似传奇的游戏，游戏里有装备道具，那么我们设计一个Item表，那这个表我个人理解应该是类似这样的。

　　ItemId, ItemType, Attack, DaoShu, MoFa, Defense, AttackRate, RequiredLevel, RequiredAttack, RequiredDaoShu, RequiredMofa, SellingPrice ....

　　道具根据ItemType判断到底是武器还是盔甲，所有的装备都可以根据这一张表在游戏世界里创造出来。所以战士的 重盔甲 一类的盔甲不但加防御，还可以加攻击。

　　但如果按领域驱动设计的思想来设计的话，那么可能武器会有个武器类，盔甲有个盔甲类， 武器类中的字段里不应该有防御， 盔甲类的字段里也不应该有攻击。这是这样便不方便扩展了，游戏版本的更新带来新的玩儿法是很常见的，可能以后装备再加个附魔属性之类的。基于抽象的数据库设计更适合这种场合。

二、GIT的优势

　　其实也是恰好前一阵面试被问到这个问题。GIT, SVN, TFS在不同的公司的实际生产中都用过， SVN是实习的时候用已经记不清了，只是在自己电脑上单机管理文件用。但我还是把他们写到简历里，纯属凑字数。

　　当时被问到的时候说我代码管理工具都用过啊，我多嘴说了一句我觉的GIT更好用，然后紧接着就被问到GIT相比TFS的优势在哪。我思考了一分钟没想上来，因为我觉得我得说个具体的事例来，如果说性能好，速度快，肯定会被问性能哪里好，速度怎么快，而且本身这类宽泛的回答也没有实际意义。然后我就说这个问题先放一放，可能过了几分钟十几分钟的样子，在回答其他问题的时候写心情没那么紧张了就顺便想了下这个问题，还真被我想出来了一个具体的细节，然后回答了他，面试官顿时觉得眼前一亮，不然我看已经准备叫我走人了，没什么想说的了。。。

　　其实面试的时候我边答，他拿个电脑边在那百度。。。我回去后也试着百度了一下，百度出来的答案无非也是性能好之类的泛泛的答案。

　　我个人觉得 GIT相比TFS最重要的优势在于并行工作。

　　TFS在同一个项目中，同一个文件只能由一人签出，A签出了，B就不能修改。假如A负责开发在线支付接口，B负责开发用户反馈，二者在业务上没有任何关系，但可能都要修改一个DataBase的配置文件。那么A完成工作前， B都没办法修改这个文件来进行调试。

　　在GIT下，则A和B同时可以修改同一文件，只是改完以后需要二人合作进行一下合并操作。使得并行工作成为可能。