当Subdomain遇见Bounded Context

《实现领域驱动设计》的作者Vernon根据过去几年DDD的实战经验又写了一本《领域驱动设计精粹》，日前已经在中国翻译出版。去年底出版社找到我时，读完英文原著最终还是放弃了翻译，推荐给了其余同事，并告诉他们出版后准备接受炮火洗礼。

image

不得不承认Vernon的新书在构建DDD落地体系方面较之上一本有了很大的进步，全书读起来很连贯，有肯定实践基础的团队或者个人均可直接上手书中很多的实践。并且通过一个案例完整叙述了从需求分析开始到最后的团队迭代开发。当然迭代运作过程中的工作量预计方式，在我看来过于简单粗暴，尽管强化了架构的最终代码落地，但却可能造成一系列的僵化。

本文主要针对Vernon一直以来对Subdomain和Bounded Context的一对一映射关系进行探讨。目标是让更多同学意识到这个方面的不同声音，从而能够加深对这两个概念存在意义的了解，并建立自己的判断。

区分问题和处理方案是个老大难问题

问题和处理方案总是像一对难以分辨的孪生兄弟，一个人看到的哥哥可能就是另一个人认为的弟弟。如同程序员在开发Story时，Story成了我们要处理的问题，具体的代码实现成理解决方案；但当BA在分析同样一个Story时，问题就成了对应的业务需求，Story只是分析出的处理方案的形容。

当然这个区分有时候可能并没有那么重要，Story究竟是一个问题，还是一个处理方案，其实我们在迭代过程中并不是很关心。但有时候不做问题和处理方案的区分确是十分危险的，甚至会造成整个产品的失败。这样的例子当然是一抓一大把的，比方我经常提及的为税务审计人员提供屏幕上多记录的翻页功能，就是我职业生涯中记忆最深刻的一次失误，想当然地采使用了“通使用”处理方案。

Eric Evan在构建DDD的体系时显然是思考了问题和处理方案这两个维度的，我相信这个过程也是十分痛苦的，以至于最后呈现在书里的实践并没有做非常明确地划分。对于后面的实践者，包括我们自己，都存在着不一样的解读。我们曾经探讨过一个DDD实践的象限划分，但因为这样的划分太过主观，结果是一组很长的邮件探讨。

象限如下图所示，这是一个好像“PHP是世界上最好语言”般的探讨，建议大家慎入，以免上火。

image

(从问题/处理方案和战略/战术 维度分析DDD元模型的元素）

这样的象限分类的确有点简单粗暴，但Subdomain和Bounded Context却是Eric明确定义的两个核心模型概念。Subdomain是对问题域的分解，而Bounded Context是对处理方案域的分解。这两个核心概念构建起了DDD解决真实世界复杂度的根基。

建模过程中很多同学其实是忽略Subdomain的，反正目标是Bounded Context。当问题相对简单时，Subdomain的划分的确给人感觉是自寻烦恼，划出Bounded Context后反过来推Subdomain视乎更容易上手。读《领域驱动设计精粹》时你会发现类似的逻辑，配合书中敏捷项目管理工具的案例（问题也挺简单）还是挺好使用的。

那么为什么我们还要关注Subdomain，还要去区分什么Core Domain、Support Domain和Generic Domain呢？能否和Story一样，留给业务和BA就好，程序员还是应该抓紧搞完Bounded Context，而后开写微服务比较务实呢？

区分Subdomain的必要性

在帮助一个长期合作伙伴构建大规模DDD应使用时，我写了一个“xx阶xx步”的体系。也成了很多咱们同事体系性学习DDD的开始。

一年半以后这个团队组织了所有的技术专家和主管让我又讲了一次这个体系。这次我花了一天时间让大家体会问题和处理方案的区别，加入了Subdomain的概念。参与团建时，我问了几个专家和主管他们怎样看之前的设计，得到更多是务实的“赞叹”。其实我并不在意具体落地时的裁剪，但希望白纸黑字时应该明确原委，这也是我为什么拒绝了《领域驱动设计精要》翻译的起因。

我经常使用电商的案例让大家快速认识到Subdomain划分的重要性。大浪淘沙之后我们发现淘宝和京东仍然是霸主。当年马爸爸嘲笑强哥构建人肉物流网的寓言也并没有发生，反而很多人爱上了京东自有物流的速度。当然站在马爸爸当年对电商问题的认知角度，自建物流是可笑的，毕竟他要处理的核心问题是如何让琳琅满目的中小供应商能够直接对接千千万万的使用户，让使用户能够更容易的发现适合的商品。

image

所以从一开始淘宝和京东定义的Core Subdomain就是不一样的，正是问题认知的区别让两家都活了下来，并且活得很好。我们可以看到在线物品展现，吸引消费者方面淘宝一直在引领；而行业里假如你有机会接触电商领域，会发现京东物流系统还是蛮厉害的。

这是我们多年后的今天看到的结果呈现，但其实真正决定命运和格局确实是多年前两家电商对自身核心问题的了解。这个认知驱动出了两家完全不同的成功电商。

很多同学会说这玩意儿是商业模式，也轮不到我们搞研发的参加。我们拿到的都是既定问题了，再识别Subdomain也没啥意义了。这个论断有两方面问题：

• 作为产品和服务的实现者，假如都不参加和关注问题本身的划分及核心子问题的认知，那么你很可能在白费自己的时间，开发出未来被边缘化，甚至淘汰的系统。这不是危言耸听，在我的最近咨询过程中已经鉴证了很屡次，比方在这个移动优先的时代去强化PC应使用的技术架构。
• 其次在这个软件应使用空前发展的时代，始终抱着所有板块都必需是“自研”，所有代码都必需自己写的思想，毫无疑问只能成为“小作坊”。构建现代的复杂系统已经逐渐成为一个生态工程，随着数字化服务的普及，识别哪些领域应该直接外购用也成为了开发团队的重要能力，构建一个典型的移动应使用应该没有人再会去重头写一个二维码扫描板块，而是学会从市场上选择适合的软件包。

那么什么地方应该建，什么地方应该买，应该如何决定呢？这时候我们会发现Subdomain的划分就非常有指导意义了。相似二维码扫描这样的Generic领域显然应该是外购的，而当年京东对电商的了解来看物流系统是要自建的。同样道理还有上次DDD China大会来分享的盒马生鲜，半年时间已经重写了三次核心ERP系统。不去思考问题划分的同学们会觉得盒马疯了，ERP在外部看来是多么成熟的软件包啊~ 但事实上盒马生鲜的本质就在如何处理生鲜食品的高效配送上，也可以说是一家特殊的物流公司。

image

小结一下，即便区分问题和处理方案很笼统，划分子问题很烧脑，我们还是必需认识到分析问题本身的重要性和必要性。借使用雷布斯的成名句“不要使用战术上的勤奋掩盖战略上的懒惰”！

Subdomain和Bounded Context的对应关系？

讨论了Subdomain的必要性，自然我们需要分析和处理方案这边Bounded Context分解的关系。第一次看Eric构建的DDD模型脑图（如下）时，我一直认为少画了Subdomain和Bounded Context的对应关系。最早采使用DDD时，个人认知是一个Subdomain下应该有多个Bounded Context，即当我们分析出了一个子问题后在针对建模的处理方案进行分解，成为多个Bounded Context。所以Subdomain：Bounded Context应该是1：N的关系。

image

（Eric构建的DDD模型脑图）

然而Vernon一直以来的实践方式隐含着1：1的对应关系。这样的对应关系并非没有道理，假如咱们从一个Bounded Context出发，我们会发现每个Bounded Context必然应该是“处理”部分问题的，而这个部分问题能否就应该是一个Subdomain呢？

当我们拿着这个差异去跟Event Storming的发明者Alberto Brandolini探讨时，发现对方婉转地表达了N：N的了解。简而言之没有直接的对应关系。当然这种了解隐含了一个Bounded Context是可以服务于多个Subdomain子问题的。比方“产品展现”Bounded Context的模型可能服务于产品销售和产品评论两个Subdomain子问题。

这三个对应关系的了解暴露出了大家对问题和处理方案这个老大难问题的纠结~ 当然最简单的是能够建立一对一的映射，作为处理方案高手的程序员们显然是非常喜欢这个模式的。以至于很多使用DDD建模的程序员直接就跳过Subdomain搞起了Bounded Context。当然这也是我坚决反对这样简单化映射关系的重要起因。

出于对方法实操性的考虑，我依然认为一对多的映射是最优的选择。固然在我们的现实世界里，问题和处理方案是没有必然对应关系的，他山之石可以攻玉也是古来有之的。但软件设计本身就是一个问题笼统的过程，这个笼统肯定会选取一个视角，也就会放弃部分信息。在这样的认知下，其实我并不介意在不同子问题的处理方案里存在肯定的重复。

所以，假如让我来站队Subdomain和Bounded Context的对应关系，我依然会选择一对多。在精确性和易使用性之间寻求一个平衡，并保证大家能够更多的关注问题本身。

坚持持续认知问题

Subdomain和Bounded Context的探讨随着DDD实践的深入会进一步被大家所探讨，不管大家能否能够共识，这样的探讨都是有好处的。作为软件开发的从业者，在面对这个越来越多不确定性的数字化时代，认知问题本身将越来越重要。

Subdomain和Bounded Context在实际认知过程中肯定也是相辅相成，逐渐清晰的两个概念。Bounded Context建立肯定是针对Subdomain的；而Subdomain的划分又会通过Bounded Context的模型得到持续地验证。

文/ThoughtWorks 肖然

上一篇 目录 已是最后