我找到合适的粒度来为我的模型定义域，子域和有界上下文时遇到问题。域驱动设计：定义业务的域和子域
在工具制造商的领域，核心领域可能是“生产”，子领域“销售”，“财务”， “备件”和“经销商管理”。经销商管理系统可能是子域“经销商管理”中的有界环境
但是在项目中，开发经销商管理系统时，“经销商管理”被定义为业务领域。 这里的核心领域是“零售商网络”，子域名：“合同管理”，“活动”和“零售商关怀”。 核心领域“零售商网络”中有界的上下文是“经销商网站”和“地理”。
在我的示例中，整个业务的子域（零售商管理）也被定义为域并分成子域。
这是正确的吗？定义域是一个透视问题还是我错了概念？
正如评论者@AlexeyZimarev正确指出的那样，您对域和边界的定义是否正确完全取决于对业务的理解。这是我们在这里无法做到的。
但是，我想提供一个技术拐杖，帮助我至少创建有界的上下文（==微服务）。这是：
有界的上下文不得要求与其他上下文同步通信才能执行其业务逻辑。
我不只是指技术上的同步。如果在上下文之间存在异步消息传递系统，但上下文必须等待答案，那仍然是同步的。
如果删除了所有其他上下文（服务已停止），则有界上下文仍然可以工作。
我认为这是很难的部分，然后将它们分组到域中，决定哪个是核心域，哪些是支持域等，这不是一项技术任务。
注意：在不知道您的情况下，“经销商管理”和“合同管理”通常是不好的有限上下文的候选项。如果其他上下文需要与“合同”或“经销商”合作，那通常是同步通信。他们需要“获得”合同，然后用它做点什么。这意味着上下文并不是真正有界的。
我认为你是对的。但是，只要确保你不会过分隔离有限的上下文。微服务体系结构也有其缺陷。 – plalx
查找上下文边界是DDD中最不平凡的。它需要广泛的知识处理流程，与领域专家一起工作一段时间，确定他们的需求，找到该语言的语言和背景。根据一个100字的问题，你不可能*回答你“正确”或“错误”。更甚者，这将是不负责任的。 –