浅谈 DDD 领域驱动设计

文章简介

在B端产品研发及项目实施中，DDD带给我们哪些思考？我们是如何应用的？本文不是科普贴，旨在分享我们的经历和思考。

背景

Domain Driven Design（简称 DDD），又称为领域驱动设计，起源于杰出软件建模专家Eric Evans在2003年发表的书籍《DOMAIN-DRINEN DESIGN —TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》（中文译名《领域驱动设计—软件核心复杂性应对之道》）。随着2014年Martin Flower和James Lewis的《Microservice》出版，微服务概念为业界所接受，DDD也被重新提起。人们发现，DDD里的领域、限界上下文、领域模型等理念，和微服务的高内聚、低耦合理念有着天然契合，越来越多的人把DDD作为指导微服务划分的方法论之一，也有越来越多的人认为，掌握DDD才是一名优秀的架构师。

DDD工作流程 - 图片来自于网络

限界上下文 - 图片来自于网络

为什么我们要开始DDD？

笔者所在团队于2015年左右开始进行公司自主产品的研发，当时，DDD主要应用在我们的微服务划分、代码分层中，对我们当时从技术角度出发、搭建统一的微服务技术框架，有着重要的指导意义。而真正开始思考将DDD应用在具体的业务领域与业务场景中，是在2018年末。那时，我们面临着自主产品实施的项目越来越多、需要帮助客户从0到1构建业务应用的情况，如何在企业甚至行业的复杂业务场景中找到合适的架构方案，是当时我们期望借助DDD去更体系化回答的问题。

我们是如何应用DDD的？

在DDD的实践中，大多数人应该都会面临一个问题：名词太多！“领域”、“子域”、“限界上下文”、“聚合”、“实体”、“值对象”等等名词，令人眼花缭乱。并且，DDD的理论虽然告诉了我们名词的定义和处理原则，但是具体场景之下，到底如何基于原则去分析，好像并没有标准答案。

这也是我们在应用DDD时的最大困境，我们也在反复思考：如何在团队内统一语言、如何把DDD原则融入到具体可执行的工作事项中？

接下来，我们将从人和事两个方面来分享我们的经历与思考。

人：

DDD里强调，领域专家和开发团队共同工作。

领域专家的加入，其本质在于让一切的设计回归业务本身，从业务价值出发，聚焦业务核心域，避免过度设计。

希望领域专家和开发团队共同工作，往往是实践中的第一个难题，如何找到合格的领域专家？如何保障领域专家的时间投入？如何最大化发挥领域专家的“价值”？

• 关于合格的领域专家：领域专家不是指某一个特定的人，可以是很多人，可相互补充，但同时也不建议过多。在寻找领域专家时，企业可以从自身的业务领域出发，在每个业务领域寻找到有丰富经验的人员。这里的“经验丰富”并不仅仅是一线实战经验丰富，更是对业务要有深度的理解和认知。
• 关于领域专家时间投入的保障：在实践中会发现，有各种各样的“客观”原因，导致领域专家无法有效投入。虽然有很多客观的情况，但是不管有多么困难，保障领域专家的时间投入都是必须要做的。如果领域专家都不参与，我们怎么有信心讲我们交付的是业务价值而不是一堆代码呢？
• 如何最大化发挥领域专家的“价值”：把抽象的问题具象化，通过聆听和引导，更多地从企业的领域专家处获得信息，放弃“我是专家”的执念。

开发团队：在多数的信息化项目中，常见的分工是需求分析师进行需求收集与设计，技术人员负责开发和实现，需求分析师进行测试验收。在DDD实践时，建议开发团队的业务架构师、技术架构师、测试架构师从一开始便共同工作，这样才能够发挥每个角色在各自专业领域的长处、逐步统一语言、快速达成共识。

事：

DDD区分了战略设计与战术设计两个层次，提出了聚焦核心域、创造性协作、统一语言的三个原则。很多人在刚开始应用DDD的时候，会感觉自己都“不会说话”、“不会做事儿”了。这其实是因为过于关注名词本身，陷于对名词的理解和解释上，因此，在“事”上，我们认为，需要抓住两个要点。

• 找到更舒服的方式

DDD通过战略设计解决业务边界划分的问题，通过战术设计实现领域模型的抽象，解决的是从业务到技术的过渡。

在谈DDD的时候，一定绕不开事件风暴。“事件风暴（Event Storming）是一种快速的设计技术，让领域专家和开发人员都可以参与到这个快节奏的学习过程中。它聚焦于业务和业务流程，而非名词概念和数据。”（摘自Vaughn Vernon《领域驱动设计精粹》）。事件风暴为DDD战略与战术落地，提供了一种非常有逻辑、有体系的方法，那么在这个方法之外，还有没有其他的方法呢？答案是，有的。尤其在B端企业的信息化建设中，瀑布实施方法论、敏捷开发等等非常多优秀的方法与工具，都可以为我们所用。

在DDD的落地过程中，我们核心的是要抓住最终要获得的结果，在过程中所采取的方式，可以根据实际情况进行调整，关键是要找到一个让大多数团队成员都舒服的方式。以笔者的经历为例，有一家客户习惯了以流程图的方式进行业务梳理，在这种情况下，使用事件风暴的方式会对客户的习惯造成冲击，甚至让客户不知道如何输出。此时，我们就应该及时调整，思考流程图与事件风暴如何融合，既能以客户习惯的方式推进，同时也能拿到我们想要的结果。

• 将原则与概念形成模板与具体工作任务

一千个人有一千个哈姆雷特，每个人对DDD原则、概念都有自己的解读。为了更快速地在团队内达成DDD落地方法的“统一语言”，建议以具体的工作任务、产出物模板来承载，让团队更聚焦在目标与任务的达成上。

通过在自主产品的研发和实施项目中应用DDD并持续迭代其应用方法，我们不仅有效地完成了中台项目的实施、为客户构建了合理地应用架构，也逐步完善了项目实施方法论体系，为更广泛地项目交付和产品研发提供了助力。DDD帮助解决了产品架构设计中的一部分问题，在架构设计之后，如何保障设计的落地、高效地交付，是每个团队会面临的下一个问题。在这里，笔者推荐使用猪齿鱼这款数智化效能平台，它可以有效管理架构设计所形成的微服务或模块，拉通设计与开发，通过提供协作、测试、DevOps、容器工具，提高团队效能。

猪齿鱼数智化效能平台

现在我们是如何理解DDD的？

DDD首先是一种思想，“聚焦核心域、创造性协作、统一语言”，是关于价值发现、价值认定、讨论、聆听、共识、迭代。这种思想不仅适用于软件设计，也适用于日常工作、个人生活、家庭教育等等方面。我们不可能在每个方面都做到完美，需要识别关键要务、聚焦投入；我们也不可能独自存在，需要与人连接、深度聆听、积极反馈；我们欣喜于共识默契，也有勇气接受差异，因为正是这些差异让我们不断碰撞、更好地学习与成长。

其次，DDD是一种方法，它区分了战略设计与战术设计的，引入了限界上下文与统一语言，提供了实体、值对象、聚合、工厂、资源库等。同时，业界也有很多DDD的相关著作，可以帮助我们更有效地去理解这些概念与具体应用方法。当然，你本身所在的领域与你的过往经验，也是应用这些方法时非常值得参考的。

软件的架构，究其根本是物理世界在数字世界的映射。在DDD的应用中，我们不仅汲取DDD的思想与方法，也学习敏捷、DevOps、测试、微服务等领域知识，同时结合我们既往的经验，逐步总结和迭代了适合我们的一套架构设计体系与方法。正如Eric Evans所说的，“DDD还未结束”，我们也在持续实践与持续调整。

本文是基于笔者当前的认知与理解所形成的，欢迎留言讨论。

---

本文由猪齿鱼技术团队原创，转载请注明出处