DDD系列文章第11篇：完结篇

全文约1600字，预计阅读时间4分钟。

导读

前面10篇介绍了DDD如何入门与知识积累、DDD的实施地图与路径、DDD的四重边界（子领域-BC-分层-聚合）里的战略设计和战术设计、DDD的分层架构、领域事件架构、BFF架构，本篇做一个小结以及给出两个实际生产项目的实践案例。

01

—

DDD的架构抓手

基于目前主流的服务端都是微服务架构，DDD实践应该着眼如何深度结合微服务架构，让DDD的落地不会仅仅停留在交谈、文档、规范里。我觉得至少可以从下面4个方面找架构落地点：

1. 单个微服务的内部分层架构 - 详见DDD系列文章第7篇：可落地的DDD分层架构
2. 如何对代码进行组织、封装和分层。以清晰的职责边界编码外部请求接入、业务逻辑处理、底层依赖。
3. 服务内部的数据结构和数据流清晰、可演进。
4. 微服务数据访问架构。
5. 如何以DDD资源库风格改造ORM框架，降低数据模型对数据存储的依赖。这一点的实现相对容易，需要做到数据模型和持久化对象的分离，封装资源库的通用操作减少业务开发的重复工作。
6. 同时考虑特定场景的需求。比如租户隔离、请求链路上下文透传、通用存储字段的填充和校验、审计日志类数据的统一处理等等。这一点的实现会因为业务形态各异而需求不同，从而架构落地也会各异。
7. 微服务之间的异步通信架构 - 详见DDD系列文章第9篇：领域事件驱动架构
8. 屏蔽业务开发人员对分布式消息队列和下游消费方的依赖
9. 解耦微服务之间的接口和界面展示逻辑的BFF架构 - 详见DDD系列文章第10篇：BFF架构
10. 保持微服务聚焦自身业务领域，保持微服务接口能力的纯粹性。解耦不同数据展示需求的依赖

02

—

DDD随处可落地

DDD如何落地应该是大家最困惑的问题。就好比『知道很多道理还是过不好这一生』，拿来就有用的做法现实中往往难找并且也不可持续发展。其实要想在团队里落地DDD不用大张旗鼓，不用精密筹划。当然如果有大领导的背书和资源倾斜最好了。所以大部分时候更应该从小处做起，除了刷新团队的理念和认知，更应找到场景落地，积累经验后再逐步推广泛化。

回到DDD的初心，即管理系统的复杂度，帮助系统能随业务一起发展和演进。在DDD之前可能大家最熟悉的就是代码重构、设计模式、微服务架构治理等方法。DDD跟这些传统做法没有矛盾，相反更应该互相结合起来。拿代码重构的例子来说：

• 重构一行代码
• 命名贴近业务语义，和产品、业务人员用同一种命名语言
• 重构一个函数
• 提炼业务概念，让函数的职责和业务里的校验逻辑、计算逻辑、适配逻辑等对应起来
• 重构一个类
• 和业务模型对应起来，兼具数据和行为
• 重构一个模块，甚至系统
• 和业务的职责范围对应起来，清晰定义该做什么不该做什么
• 服务哪些业务角色、对象、流程出发，存储和管理哪些数据

总之，勿以善小而不为。业务系统的开发没有太多秘密可言，随手捡起地上的垃圾，消除概念的模糊地带。平时产研之间、研发之间的协作质量全体现在系统里了。

03

—

2个DDD的实践案例

以下是笔者在团队里主导和实施落地DDD的项目中比较典型的两个。可以结合前面的系列文章对照阅读。希望能给读者带来更直观的DDD实践体验。

案例1：

这是2年前在团队针对一个CRM SaaS系统的核心模块应用架构演进，改善团队开发效率和质量。当时的挑战是如何在团队有组织有方法地落地DDD？案例文章详见：领域驱动设计(DDD)在百度爱番番的实践。

案例2

这是一个IM即时沟通系统的业务和技术双重构案例。如何能够让技术重构既还了过去的债又能为将来业务发展产生持续的收益？产研团队如何一起协作重塑业务和技术，达到双赢？案例文章详见：当技术重构遇上DDD

04

—

结语

管理复杂度是程序员也是架构师的首要职责，除了非功能需求层面的复杂度，更多的就是来自业务的复杂度。不同领域不同业务的程序员要管理的业务复杂度姿态各异。不管技术今后如何发展，技术总归是要服务业务的。作为程序员，任何时候都不要忘记多理解业务，多提升抽象能力、结构化建模能力、与人协作的能力，而这也是DDD的内核。

感谢阅读，本篇首发于微信公众号：非写不可 - DDD系列文章第11篇：完结篇

举报/反馈