什么是 DDD

什么是 DDD(Domain-Driven Design), 搜索引擎能有一百种玄乎理解（中文环境）。

最近准备体系了解一下，花半个月看了下 《领域驱动设计》 和 《实现领域驱动设计》 两本书。

第一次听说 DDD 是在2020年末，当时在参与公司系统架构升级。

主要两件事情，一是中台的抽取，核心业务服务升级为业务中台，剥离支撑业务。二是项目代码结构分层的调整，后台大致是有原先的 Controller、Bll、Dal 调整为为 Controller、Manager、Service 和 Dal 四层。当时尝试去了解一下 DDD，发现一堆看不懂的词，比如：领域、聚合、界限上下文。

现在回头看，抽取的中台其实就类似 Core Domain, 代码的分层已经和 ui, application, domain, infrastructure 这种典型分层相当地接近了，只是各层职责略有差异。

代码结构调整目的很简单，无非是使代码更易维护。那么什么样的代码难以维护？业务多变的代码！

所以项目的核心是不仅要维护好代码结构，更重要的是维护好业务知识，按边界划分，做到高内聚，低耦合。核心业务知识和其他辅助业务、外部系统交互、数据持久化等职责划分清楚，抛弃事务脚本型的开发模式。

再来看DDD是什么，通俗的讲就是代码由边界清晰的业务模块（领域）驱动，一方面可以和业务人员方便沟通，一另方面可以相对轻松地应对需求的变更。

代码怎么落地 DDD

具体到代码层，DDD 并不局限于某种架构，不管是分层架构还是六边形架构，核心都是要围绕领域层（Domain Layer）去展开。

以分层架构为例，结合依赖倒置原则，我们应该将重心放到领域层，领域层并不依赖其他层。

代码的大致结构

“如非必要 勿增实体”

随着业务复杂度提升，可以引入 CQRS（命令与查询职责分离）来解决数据显示的复杂性。使用 EventBus（事件总线）来进一步降低耦合。