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

Question

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

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

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

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

这是正确的吗？定义领域是一个视角问题，还是我对概念有误？

Answer 1

正如评论者@AlexeyZimarev 正确指出的那样，您对域和边界的定义是否正确完全取决于对业务的理解。我们不能在这里真正做到这一点。

但是，我想提供一个技术支持，至少可以帮助我创建有界上下文（==微服务）。这是：

有界上下文不得要求与其他上下文同步通信以执行其业务逻辑。

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

如果所有其他上下文都被删除（服务停止），有界上下文应该仍然有效。

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

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