1回答

尤达_技术咖啡

2022-02-11

这里的确是一个难点，子域和限界上下文的概念很容易混淆。

每个系统解决的都是对应领域的某个方面的问题。解决任何问题，不是上来就找答案，而是先要把这个问题定义清楚，比如设计电商系统，不可能上来就开始列领域对象，因为不清楚系统要解决哪些问题（或者说需求），所以首先应该把问题列出来，但是系统太过庞大，即便把问题列出来讨论搞清楚，都要耗费大量时间，所以要先把问题划分一下，然后分头行动，比如：这个系统至少要能管理商品信息，能下订单和履约订单，能管理商品库存和采购，那就分成三个小组分头进行需求分析。注意这个时候还没有限界上下文，因为领域对象都还没出现。那怎么称呼这三个小组或者这三方面问题呢？可以就叫商品信息管理域、下订单和订单履约域、商品库存域，但是太啰嗦，那就叫商品域、订单域、库存域吧。这就是子域的含义和作用。子领域是处于问题空间的，只考虑问题，不包含解决方案，实体、值对象、聚合所有这些都还不存在。

这三个小组经过大量讨论和分析，最终和领域专家把各自需求摸得非常清除了，接下来就可以确定各自的解决方案了，在讨论这些需求的过程中，分别出现了哪些领域对象？需要哪些服务？这个时候限界上下文才开始出现，在解决库存问题的时候，团队也许会发现市场上有成熟可用的第三方服务，可以在前期降低风险和成本，决定直接把这个第三方服务集成进来，但是这个第三方服务跟我们自己的需求还是有区别，不能直接用，要作一些转换，所以最终库存域的问题，其实没有完美地映射成一个限界上下文，而是由我们自己的库存BC和第三方的库存BC配合完成。我们库存域需求分析中出现的那些领域对象和服务，构成了我们自己的库存BC，第三方库存系统内部的领域对象和服务，构成了第三方库存BC。限界上下文是面向子领域问题的解决方案，是处于解决方案空间的。只是碰巧，BC的名字和子域的名字一样了。

所以，简单说，子域是处于问题空间，BC处于解决方案空间。为什么要分问题空间和解决方案空间，请参考上面两段话的例子。（当然，电商系统并不只包含这几个子域，只是个例子）

9

0