category: DDD

本文首先发表于ThoughtWorks洞见。 软件项目的套路 如果你平时的工作是做各种项目（而不是产品），而且你工作的时间足够长，那么自然见识过很多不同类型的项目。在切换过多次上下文之后，作为程序员的你，自然而然的会感到一定程度的重复：稍加抽象，你会发现所有的业务系统都几乎做着同样的事情： 从某种渠道与用户交互，从而接受输入（Native App，Mobile Site，Web Site，桌面应用等等） 将用户输入的数据按照一定规则进行转换，然后保存起来（通常是关系型数据库） 将业务数据以某种形式展现（列表，卡片，地图上的Marker，时间线等） 稍加简化，你会发现大部分业务系统其实就是对某种形式的资源进行管理。所谓管理，也无非是增删查改（CRUD）操作。比如知乎是对“问题”这种资源的管理，LinkedIn是对“Profile”的管理，Jenkins对构建任务的管理等等，粗略的看起来都是这一个套路（当然，每个系统管理的资源类型可能不止一种，比如知乎还有时间线，Live，动态等等资源的管理）。 这些情况甚至会给开发者一种错觉：世界上所有的信息管理系统都是一样的，不同的仅仅是技术栈和操作的业务对象而已。如果写好一个模板，几乎都可以将开发过程自动化起来。事实上，有一些工具已经支持通过配置文件（比如yaml或者json/XML）的描述来生成对应的代码的功能。 如果真是这样的话，软件开发就简单多了，只需要知道客户业务的资源，然后写写配置文件，最后执行了一个命令来生成应用程序就好了。不过如果你和我一样生活在现实世界的话，还是趁早放弃这种完全自动化的想法吧。 复杂的业务 现实世界的软件开发是复杂的，复杂性并不体现在具体的技术栈上。如Java，Spring，Docker，MySQL等等具体的技术是可以学习很快就熟练掌握的。软件真正复杂的部分，往往是业务本身，比如航空公司的超售策略，在超售之后Remove乘客的策略等；比如亚马逊的打折策略，物流策略等。 用软件模型如何优雅而合理的反应复杂的业务（以便在未来业务发生变化时可以更快速，更低错误的作出响应）本身也是复杂的。要将复杂的业务规则转换成软件模型是软件活动中非常重要的一环，也是信息传递往往会失真的一环。业务人员说的A可能被软件开发者理解成Z，反过来也一样。 举个例子，我给租来的房子买了1年的联通宽带。可是不多过了6个月后，房东想要卖房子把我赶了出来，在搬家之后，我需要通知联通公司帮我做移机服务。 如果纯粹从开发者的角度出发，写出来的代码可能看起来是这样的： public class Customer { private String address; public void setAddress(String address) { this.address = address; } public String getAddress() { return this.address; } } 中规中矩，一个简单的值对象。作为对比，通过与领域专家的交流之后，写出来的代码会是这样： public class Customer { private String address; public void movingHome(String address) { this.address = address; } } 通过引入业务场景中的概念movingHome，代码就变得有了业务含义，除了可读性变强之外，这样的代码也便于和领域专家进行交流和讨论。Eric在领域驱动设计（Domain Drvien Design）中将统一语言视为实施DDD的先决条件。 层次架构（三明治） All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections....

DDD为什么很难实施 领域驱动设计（Domain Driven Design）的概念已经被发明了十多年，而且也不乏相关著作，但是业界宣称自己应用了DDD原则的项目，软件却鲜有耳闻。随着微服务架构的流行，DDD在边界识别，服务划分等方面不断被提及，作为一种应对复杂软件的方法论，似乎又被重视起来了。 那么，为什么这个听起来很靠谱的方法论实际上很难实施呢？我们以DDD创始人Eric Evans的经典书籍《领域驱动设计：软件核心复杂性应对之道》为例，分析一下，可能的原因是这样的： 新概念数量比较多 战术/战略都有所涉及 不同层次的概念混杂（除了设计模式之外，还有架构风格的讨论）在一起 繁复而混杂的概念 领域，子域，核心子域，通用子域，实体，值对象，领域服务，应用服务，领域事件，统一语言，衔接上下文，遵循者等等。DDD中有着大量的新概念，而且这些概念有些是技术相关的，有些是问题相关的，交织在一起之后，很难理清头绪。 DDD中的模式又分为战术的和战略的两大部分，有很多团队应用了战术相关的，比如实体，值对象，领域服务，仓库等模式，代码看似DDD，实则与DDD强调的以领域为中心相去甚远，陷入了开发者太过于关注技术本身的老路上，这种现象还有个专门的名词，叫DDD-Lite。 不同的思维方式要求 DDD要求读者既有具体Coding的技能，有需要跳出圈外，以架构师的角度来审视整个系统。DDD需要开发者以一个全新的视角去认识软件开发，强调对业务流程的熟悉，强调与领域专家一起协作，强调软件的表达能力和进化能力。而这些思维方式的转变，都有很大阻力的（想想从面向对象世界切换到函数式编程，再到响应式函数编程的切换）。 It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. – Nathaniel Borenstein 我自己在工作的前4年，非常反感业务，认为case by case的业务流程会严重影响我的代码的通用性。然而事实是，纯粹通用的代码是不存在的。毕竟，诸如IoC容器，Web等基础设施已经相当完善，完全无需我们重复发明轮子。而作为应用开发人员，更重要的是在充分理解业务的前提下，写出易于维护，易于扩展，可以更快速响应业务变化的代码。 正因为如此，DDD在一定程度上会让程序员感到不适，它太强调领域了，而领域又是独一无二的，每个公司的每个系统都有其独立性，这就要求你的代码可能没法做到纯粹。 正确姿势 要解决上面提到的这些问题，正确的实施DDD来指导实际的开发工作，需要至少做到这样几个事情。首先，明确分清问题和方案（这是初学DDD者最容易犯的错误）；其次，转变思维方式，将软件开发的重心放在梳理并明确业务需求上，而不是代码逻辑上；最后，需要应用一些合理的工程实践来促成DDD-Lite的落地。 分清问题和解决方案 我们说领域（子域，通用子域，支撑子域等）的时候，是在讨论问题域，即定义我们要解决的问题是什么。而说到限界上下文，聚合，实体，仓库则是在讨论解决方案部分，人们很容易将两者搞混。 在电商的领域中，一些典型的问题是： 如何获得更多的客户 如何让客户更快速的找到自己想要的商品 如何准确的推荐相关产品给客户 用户如何付费 要解决这些问题，人们可能会开发出来一个软件系统，也可能会用手工的流程，也可能是混合模式。同样，一些具体的解决方案的例子是：...