分解子網域 - AWS 規範指引

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

分解子網域

此模式使用領域驅動設計（DDD）子域來分解巨石。這種方法將組織的領域模型分解為單獨的子網域，這些子網域被標記為核心 (企業的關鍵差異因素)、支援 (可能與業務有關，但不是差異化項) 或一般 (非特定業務)。這種模式適用於在子域相關模塊之間具有明確定義界限的現有整體系統。這意味著您可以通過將現有模塊重新打包為微服務，但無需重寫現有代碼來分解整體性。每個子域都有一個模型，並且該模型的範圍稱為有界上下文。微服務是圍繞這個有界的背景開發的。下表說明使用此模式的優點和缺點。

優點 缺點

  • 鬆散耦合的架構提供可擴充性、彈性、可維護性、可擴充性、位置透明度、通訊協定獨立性和時間獨立性。

  • 系統變得更具擴展性和可預測性。

  • 可能會建立太多的微服務，這使得服務探索和整合變得困難。

  • 商業子網域難以識別，因為它們需要對整體業務有深入的了解。

下圖顯示了保險整體在被業務能力分解後，如何將其分解為子網域。

通過子域分解巨石

該圖顯示銷售和行銷服務分解為較小的微型服務。採購和索賠模型是銷售人員的重要業務差異因素，並分為兩個獨立的微服務。營銷是通過使用支持的業務功能，如活動分解, 分析, 和報告.