我找到合適的粒度來爲我的模型定義域，子域和有界上下文時遇到問題。域驅動設計：定義業務的域和子域
在工具製造商的領域，核心領域可能是「生產」，子領域「銷售」，「財務」， 「備件」和「經銷商管理」。經銷商管理系統可能是子域「經銷商管理」中的有界環境
但是在項目中，開發經銷商管理系統時，「經銷商管理」被定義爲業務領域。 這裏的核心領域是「零售商網絡」，子域名：「合同管理」，「活動」和「零售商關懷」。 核心領域「零售商網絡」中有界的上下文是「經銷商網站」和「地理」。
在我的示例中，整個業務的子域（零售商管理）也被定義爲域並分成子域。
這是正確的嗎？定義域是一個透視問題還是我錯了概念？
正如評論者@AlexeyZimarev正確指出的那樣，您對域和邊界的定義是否正確完全取決於對業務的理解。這是我們在這裏無法做到的。
但是，我想提供一個技術柺杖，幫助我至少創建有界的上下文（==微服務）。這是：
有界的上下文不得要求與其他上下文同步通信才能執行其業務邏輯。
我不只是指技術上的同步。如果在上下文之間存在異步消息傳遞系統，但上下文必須等待答案，那仍然是同步的。
如果刪除了所有其他上下文（服務已停止），則有界上下文仍然可以工作。
我認爲這是很難的部分，然後將它們分組到域中，決定哪個是核心域，哪些是支持域等，這不是一項技術任務。
注意：在不知道您的情況下，「經銷商管理」和「合同管理」通常是不好的有限上下文的候選項。如果其他上下文需要與「合同」或「經銷商」合作，那通常是同步通信。他們需要「獲得」合同，然後用它做點什麼。這意味着上下文並不是真正有界的。
我認爲你是對的。但是，只要確保你不會過分隔離有限的上下文。微服務體系結構也有其缺陷。 – plalx
查找上下文邊界是DDD中最不平凡的。它需要廣泛的知識處理流程，與領域專家一起工作一段時間，確定他們的需求，找到該語言的語言和背景。根據一個100字的問題，你不可能*回答你「正確」或「錯誤」。更甚者，這將是不負責任的。 –