浅谈领域驱动设计

　　首先，不提及有关本主题的话题，先谈一下“工作经验”与“薪资待遇”的关系，公司招聘时划分工资等级，往往都是应届本科3k起，应届研究生5.5k起，1-2年...， 3年.... 一名5年经验的人来公司面试(说自己是中科院所属公司出来的)，问个静态类与单体模式有什么不同，二者如何选择，他几乎没回答，只是把概念叙述了一下。
在此我只想表达一个看法：靠年限熬到的team leader，你不一定具有那个实力或能力，当然我承认team leader的团队领导能力，而且这一点也十分重要。

　　园子内外有一些关于DDD的文章，作者也都是蛮有来头，似乎没有什么资格评论别人，但是我看到那些举例往往都是敷衍了事，相比之下还是老外比较在行一些。

　　领域驱动设计，核心在于什么？ 是领域？是驱动？还是设计？答案应该是“领域”吧！那么对于一个根本就没什么门槛的行业项目而言，却拿来进行领域建模？！想要用领域模型来解决的是什么，往往就会陷入“以数据为中心的应用开发”之中，领域模型就成了E-R图。

　　领域模型，是用来抽象企业复杂流程的，是行业专家与开发人员的中间交流的媒体，架构师/分析师在与行业专家交谈过程不断深入了解行业知识，进而不断修改完善领域模型，这一过程需要使用的UML类图来完成，注意类的关系：泛化，关联、组合/聚合，而且类是具有行为--方法，每个方法就是某一业务流程的处理逻辑，同时还要注意多态性，一个类就是领域模型中的一个实体，但它不一定就对应某个数据库中表。

　　领域模型的实体，实体具有属性和方法，那么从实体到数据库，这一步很关键，也很麻烦，实体与表不非一一对应，实体中间的泛化关系如何处理？相信很多人都在使用ORM，那么ORM正是解决方法。此处本人推荐ADO.NET EF，当然很多老者喜欢NH，我没有用过NH，不过感觉NH与EF不是一个等级的框架，ORM的核心在于动态获取和执行计划吧，NH也许支持动态SQL，但应该不支持动态获取、状态跟踪，NH映射的Model就是一个DTO，另外就是Model First可以极大的简化领域模型实体到数据库的映射，就算是直接映射数据库也可继续修改完善EDM。

　　领域模型的设计，此过程最为重要，在实际过程中，甚至会走到推翻重来的尴尬地步，原因主要是在于不断了解业务之后的“突破”--发现先前的模型什么都不是。

总结一下应如何进行领域驱动设计：

1. 与行业专家面对面交流的机会，善于捕捉领域问题，并且以最接近行业的术语向专家描述问题
2. 不断“突破”，即使推翻重来，也是必要的，“突破”表明离成功更进一步
3. 进行领域建模，良好的OO思想，泛化、多态是重点，关联、封装是基础，熟悉UML，至少是类图设计
4. 良好的表达能力，向开发团队展示你的领域模型

在第2-3步中，关键在于类的方法的设计，什么实体该具有这个方法，方法是否被可以重写，哪些方法应该跟随这个实体，就如同在设计类库一样，设计不好，在编码阶段就会变得混乱，另外一点就是领域驱动设计过程会忽略数据库设计，数据库优化，如索引、分区需要单独分析处理。

　　曾有人提出DDD过程应无法进行文档化，DDD是基于OOAD发展而来，我认为依然会使用UML视图，用例图、序列图不可缺少，数据库详细设计就由实体模型来代替，领域实体就是类图，DDD产生文档应该就是类图+类的详细设计了。

　　本人只是进行了Model First（因为相关业务逻辑的算法都提前封装实现了，在领域实体中未进行泛化和方法设计），先算是领域驱动设计的一次浅尝试吧，这一尝试过程，曾经1次推翻重来，其实后来到项目上线时候，又发现了新的业务问题，这次是真正的“突破"，让人感到害怕，因为原来那些算法逻辑真的面临推翻的危险....，原因在于整个分析和设计过程未与行业专工进行任何交流，仅是根据一个doc文档内容来分析设计，里边的业务流程描述并非全理解。
　　毕竟，一个刚毕业不久的家伙，也不太可能说服领导让我去做需求调研......

　　诸如银行的企业级融资信贷业务系统、核工业的瞬变统计和资产管理系统，行业性越深，越值得进行领域驱动设计；总不能一个校园图书馆系统、企业OA拿来搞领域驱动吧。

　　要抓住领域驱动设计的初衷，它是为了解决软件复杂核心业务而产生的。