区分问题和解决方案是个老大难问题

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

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

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

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

（从问题／解决方案和战略／战术维度分析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，然后开写微服务比较务实呢？