文章简介

在 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 还未完结”，咱们也在继续实际与继续调整。

本文是基于笔者以后的认知与了解所造成的，欢送留言探讨。

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

对于猪齿鱼

猪齿鱼 Choerodon 数智化效力平台，提供体系化方法论和合作、测试、DevOps 及容器工具，帮忙企业拉通需要、设计、开发、部署、测试和经营流程，一站式进步管理效率和品质。从团队协同到 DevOps 工具链、从平台工具到体系化方法论，猪齿鱼全面满足协同治理与工程效率需要，贯通端到端全流程，助力团队效力更快更强更稳固，帮忙企业推动数智化转型降级。戳此处试用猪齿鱼