重新解读DDD领域驱动设计(一)

回顾

十年前，还未踏入某校时，便听闻某学长一毕业就入职北京某公司，月薪过万。对于一个名不见经传的小学院，一毕业能拿到这个薪水还是非常厉害的。听闻他学生期间参与开发了一款股票软件，股票那时正迎来一波疯涨。时也运也。我那时心里就想，只会软件也行不通吧，至少要熟悉股票规则。在还未踏入编程大门时，我就清楚的认识了软件服务于业务的本质。

等刚开始工作时，从事些较简单的工作，也是需要和使用人员讨论需求，文档编写和开发实现。性质偏向于公司内部财务人员或业务人员管理用的子系统。也许厌烦了写的代码用的人太少，于是转移到了互联网类型的公司。在日益复杂的业务与软件规模下，以前用的熟练的三板斧渐渐适应不了，知识库需要更新了。结合以前的工作实践，按自己的理解，重新解读下领域驱动设计。

第一部分运用领域模型

按照一个系统的开发步骤，除了前期招标，合同，预算，人员规划等其他项目管理的范畴外，真正执行到系统部分是从沟通业务需求开始的。

第一章消化知识

几年前我们要做一个院系资产管理系统，最开始理解的有人申请，管理员审核购买，分发扣库存的逻辑。实际讨论下来之后，分为很多流程。如设备提申请，教务处审批，院系审批，提交财务核账。又涉及到固定资产折旧，退货流程，又要财务核对。又有家具的申请与退货等其他。还有定期的报表功能。基于我们开发人员和校方人员，都对资产审核，退货，对账流程都有一定熟悉度，所以沟通下来业务大框架还算顺利。我理解为我们在沟通业务的过程中，有了相似的认识，并在磨合过程中，修炼完善。DDD一书中，以PCB电路板软件工具为开篇，讲述了PCB专家和开发人员沟通中从最开始的很难沟通，到最后依据流程图及PCB元件执行逻辑完成了语言上的沟通统一。很幸运，我们大部分的业务并没有如文中跨度那么大。

在沟通的过程中，业务专家需要理解共同构建的业务模型，开发人员也要依据业务模型来勾思大概实现逻辑。就比如设备申请，家具申请,XX申请;设备退货，资产退货。这些有共同性，又有差异的流程，如何更好的抽象，来实现复用？如果单纯开发人员自己抽象得到概念有可能是很幼稚的，开发出来的软件只能做基本工作，无法充分反映领域专家的思考方式。

领域专家和开发人员共同参与，一起来丰富抽象的模型。提炼模型，对于领域专家来说也是升华自己思考完善自己理解的过程。会更加注重概念的严谨性。

模型在不断改进的同时，也称为组织项目信息的工具。模型聚焦于需求分析。它与编程和设计紧密交互。

知识丰富的设计

举一个判断是否合并账号的逻辑。一个请求中的手机，邮箱账号，根据账号的是否验证，以及数据库中手机号邮箱的是否存在是否验证来判断是否合并账号。产品列举了81条合并规则。

我最开始想到了策略设计模式。根据各种状态分析出主要的几个策略来实现判断。工作量相当复杂，而且易出错。同事建议了另外一种规则式的实践。对比新账号的状态和筛选中的存在账号状态，形成一个规则，看这个规则符合那81条规则的哪一种。这样代码量指数级下降，也通用。而且其他人也更容易根据产品的文档，直接看懂代码。模型与实现一致。

书中依据航线超卖为例，举了两个例子，一个是简单的if超卖判断，一个把超卖独立成一个策略类来判断超卖。并强调超卖在模型中不仅仅是一个简单的判断，而是一个让所有人看到代码都明白是一个独特的策略。

经过以上对比，你会发现设计模式有它自己的适用场景，不要随便套用。第二点设计的模型和代码实现一致。

深层模型

说到太极，外是软绵绵的一套动作。如果按软件直接开发，实现出来的是错的。因为陈家沟的领域专家们会告诉你太极每一招都是制人招。这个我信，如果有人喂招的话，分秒钟被干到地，对付普通人还是有效的。

这里说的后续的制人招是深层模型，我们看到的慢腾腾的动作是表层。这样说很容易理解。

第二章交流与语言的使用

通用语言

领域专家和开发人员语言要一致。将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。

书面设计文档

文档应作为代码和口头交流的补充

文档和图

用图来沟通交流，能促进头脑风暴。但模型不是图。