领域驱动设计:定义业务的域和子域

Question

我很难找到合适的粒度来为我的模型定义域、子域和有界上下文。

在工具制造商的领域，核心领域可以是“生产”、子领域“销售”、“金融”、“备件”和“经销商管理”。经销商管理系统可以是子域“经销商管理”中的有界上下文。

但在项目开发中，经销商管理系统的开发将经销商管理定义为业务领域。这里的核心领域是“零售商网络”，子域是“合同管理”、“活动”和“零售商关怀”。在核心领域“零售商网络”中有界的上下文是“经销商站点”和“地理”。

在我的示例中，整个业务的子域(零售商管理)也被定义为域，并划分为子域。

这是正确的，界定领域是一个透视的问题，还是我的概念错了？

Answer 1

正如注释@AlexeyZimarev正确指出的那样，您对域和边界的定义是否正确完全取决于对业务的理解。但我们在这里做不到。

然而，我想提供一个技术支柱，至少可以帮助我创建有限制的上下文(==microservices)。这是：

有界上下文必须不需要与其他上下文同步通信才能执行其业务逻辑。

我指的不仅仅是技术上的同步。如果上下文之间存在异步消息传递系统，但是上下文必须等待答案，那么这仍然是同步的。

如果删除了所有其他上下文(服务被停止)，那么一个有限制的上下文仍然可以工作。

我认为这是困难的部分，然后将它们分组到领域，决定哪个是核心领域，哪些是支持领域等等，这不是一项技术任务。

注意:在不了解你的情况的情况下，“经销商管理”和“合同管理”通常都是有限上下文的坏候选者。如果其他上下文需要与“合同”或“经销商”一起工作，则通常是同步通信。他们需要“得到”一份合同，然后用它做点什么。这意味着上下文没有真正的限制。