Subdomain和Bounded Context的对应关系？

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

（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的对应关系，我仍然会选择一对多。在准确性和易用性之间寻求一个平衡，并保证大家能够更多的关注问题本身。