識別每個微服務的模型界限和大小時，目標不是要達到最細微的分離，但如果可能，您應該傾向於使用小型微服務。 相反地，您的目標應該是運用領域知識來達到最有意義的劃分。 重點不是大小，而是商務功能。 此外，如果根據大量相依性，應用程式的特定區域需要明確的凝聚力，則表示單一微服務的需求也一樣。 凝聚力是識別如何分割或分組微服務的方法。 最後，當您深入瞭解網域時，您應該反覆調整微服務的大小。 尋找合適的大小不是一蹴而就的過程。
Sam Newman 是知名的微服務推廣者，也是《Building Microservices》一書的作者，強調您應該根據界限上下文（BC）模式（屬於領域驅動設計的一部分）來設計微服務。 有時候，BC 可以由數個實體服務組成，但反之亦然。
具有特定領域實體的領域模型會套用在具體的 BC 或微服務內。 BC 會分隔領域模型的適用性，並讓開發人員小組成員清楚且共同瞭解哪些內容必須有凝聚力，以及可以獨立開發的內容。 這些是微服務的相同目標。
另一個指導設計選擇的工具是 康威定律，該定律指出應用程式將反映該組織產生的社會分界。 但有時，情況正好相反，-the 公司的組織是由軟體構成的。 您可能需要逆轉康威定律，並按照您希望公司組織的方式來建立界限，偏向於業務流程諮詢。
若要識別限定的內容，您可以使用稱為 「內容對應」模式的 DDD 模式。 使用上下文映射，您可以識別應用程式中的不同上下文及其界限。 例如，每個小型子系統都有不同的內容和界限。 語境映射是用來清楚界定網域之間界限的方法。 BC 是自主的，包含單一網域 -details 的詳細資料，例如網域實體，並定義與其他 BC 的整合合約。 這類似於微服務的定義：它是自主的，它會實作特定網域功能，而且必須提供介面。 這就是為什麼內容對應和限定內容模式是識別微服務領域模型界限的好方法。
設計大型應用程式時，您會看到其領域模型如何被分割。例如，目錄及庫存網域中的領域專家會在命名實體時採用與出貨領域專家不同的方式。 或者，在處理想要儲存客戶每個詳細數據的CRM專家時，使用者網域模型的大小和屬性數量可能會有所不同，相比於只需要客戶部分數據的訂購領域專家。 很難在與大型應用程式相關的所有網域中釐清所有網域字詞。 但最重要的是，你不應該試圖統一條款。 相反地，請接受每個網域所提供的差異和豐富性。 如果您嘗試為整個應用程式建立統一的資料庫，那麼詞彙的統一化嘗試會顯得不自然，對任何一位多領域專家來說聽起來並不合適。 因此，BC（實作為微服務）將協助您釐清何處可以使用特定領域術語，以及何處需要分割系統並建立具有不同領域的其他 BC。
如果您定義域模型之間沒有很強的關聯性，而且執行一般應用程式作業時，通常不需要合併多個領域模型的資訊，您就會知道每個 BC 和領域模型都有正確的界限和大小。
或許每個微服務的領域模型應有多大的最佳答案是：它應具有一個盡量獨立的界限上下文（BC），這可以讓您在不需要頻繁切換到其他上下文（其他微服務的模型）的情況下進行工作。 在圖 4-10 中，您可以看到多個微服務（多個 BC）各自擁有自己的模型，以及如何根據應用程式中每個已識別領域的特定需求來定義其實體。
圖 4-10。 識別實體和微服務模型界限
圖 4-10 說明與在線會議管理系統相關的範例案例。 根據限定的內容，相同的實體會顯示為「使用者」、「購買者」、「付款人」和「客戶」。 您已根據定義領域專家為您定義的領域，識別出數個可實作為微服務的 BC。 如您所見，有實體只存在於單一微服務模型中，例如付款微服務中的付款。 這些將很容易實作。
然而，您可能也有一些實體，它們雖然形狀不同，但在多個微服務的領域模型中共享相同的身份。 例如，會議管理微服務中會識別用戶實體。 具有相同身分識別的相同使用者是訂購微服務中的「購買者」，或「付款」微服務中名為 Payer 的「購買者」，甚至是客戶服務微服務中名為 Customer 的使用者。 這是因為，根據每個領域專家正在使用的 無處不在的語言 ，使用者可能有不同的觀點，即使有不同的屬性。 微服務模型中名為「會議管理」的用戶實體可能具有大部分的個人資料屬性。 然而，在微服務「付款」中作為「付款者」或微服務「客戶服務」中作為「客戶」的同一位使用者可能不需要相同的屬性清單。
圖 4-11 中說明類似的方法。
圖 4-11。 將傳統數據模型分解成多個領域模型
在有界上下文之間分解傳統數據模型時，您可以有不同的實體，這些實體會共用相同身份（購買者也是使用者），且每個有界上下文中有不同的屬性。 您可以看到使用者在「會議管理」微服務模型中以「用戶」實體的形式呈現，同時在「定價」微服務中以「購買者」實體的形式出現。在用戶實際作為買家時，會包含不同的屬性或詳細資訊。 每個微服務或 BC 可能不需要與使用者實體相關的所有數據，只是其中的一部分，視要解決的問題或內容而定。 例如，在定價微服務模型中，您不需要位址或用戶名稱，只需要用戶ID（作為身份識別）和狀態，這會在為每位買家定價座位時對折扣產生影響。
Seat 實體在每個領域模型中具有相同的名稱，但有不同的屬性。 不過，Seat 會根據相同的標識符來共用身分識別，就像使用者和購買者一樣。
基本上，有多個服務（網域）中存在用戶共用的概念，這些服務全都會共用該使用者的身分識別。 但在每個領域模型中，用戶實體可能會有其他或不同的詳細數據。 因此，必須有一種方法，才能將用戶實體從某個網域（微服務）對應到另一個網域。
在不同網域中不共用具有相同屬性數目的相同用戶實體有幾個優點。 其中一個優點是減少重複，讓微服務模型沒有任何不需要的數據。 另一個優點是擁有每個實體特定數據類型的主要微服務，以便只由該微服務驅動該數據類型的更新和查詢。
