第二篇：工具篇之DDD （一）基本认识

写在前面：要不要DDD

​ 网上关于领域驱动的相关文章数不胜数，但是就跟我一个同事说的，具体落地的到底有多少呢？我们说领域驱动最核心的就是领域模型，一个稳定的领域模型胜过千军万马，然而在当下依然是互联网的时代，业务告诉发展的时期，一切的产品设计和技术都是服务于业务，然而有多少业务是随心所欲闭门造车临时方案的情况，我想程序员们应该是深有体会。于是带来一个问题，业务层面如此的不固定，我们如何跟业务通过领域建模来统一语言，更别说稳定我们的领域模型了（一段时间范围内的相对稳定）。同时在那些不懂技术的老板眼里，他们只关注完成系统的开发通过时间点压榨，哪里管你因为使用了 DDD 而带来的开发周期和开发成本的增加，他们只会认为你技术不行，做这么简单的东西要那么久。好了，吐槽到此为止！

​ 既然没有多少企业实际落地 DDD，那我们还需要 DDD 吗？

​ 我的答案：需要，我们需要一个抓手，任何新系统的开发和老系统的重构乃至系统技术应用架构或者功能架构图，都需要一个抓手，一个切入点，一个可以撬动大家思路的武器，包括微服务的拆分，拆分的理论依据是什么？ by experience ？出于慎重考虑我们需要一个抓手，因为 DDD 可能是一个。

​ 然而虽说众多企业并没有实际落地 DDD ，或许因为其书籍和资料都过于高大上，但实际上我们平时的工作中都用到了 DDD 的部分理念和方法。例如聚合，在 DDD 建模种聚合是构建领域模型的基础。那我们在日常技术方案设计过程中多多少少都会涉及聚合，甚至我们在画 UML 类图的时候聚合就是六种关系的其中一种。

​ 本篇文章属于软实力的修炼&#x