DDD分層架構的三種模式
https://www.jishuwen.com/d/pOIC/zh-tw
DDD（Domain Driven Design，領域驅動設計）作為一種軟體發展方法，它可以説明我們設計高品質的軟體模型。在正確實現的情況下，我們通過DDD完成的設計恰恰就是軟體的工作方式。
UL（Ubiquitous Language，通用語言）是團隊共用的語言，是DDD中最具威力的特性之一。不管你在團隊中的角色如何，只要你是團隊的一員，你都將使用UL。由於UL的重要性，所以需要讓每個概念在各自的上下文中是清晰無歧義的，於是DDD在戰略設計上提出了模式BC（Bounded Context，限界上下文）。UL和BC同時構成了DDD的兩大支柱，並且它們是相輔相成的，即UL都有其確定的上下文含義，而BC中的每個概念都有唯一的含義。
一個業務領域劃分成若干個BC，它們之間通過Context Map進行集成。BC是一個顯式的邊界，領域模型便存在於這個邊界之內。領域模型是關於某個特定業務領域的軟體模型。通常，領域模型通過物件模型來實現，這些物件同時包含了資料和行為，並且表達了準確的業務含義。
從廣義上來講，領域即是一個組織所做的事情以及其中所包含的一切，表示整個業務系統。由於“領域模型”包含了“領域”這個詞，我們可能會認為應該為整個業務系統創建一個單一的、內聚的和全功能式的模型。然而，這並不是我們使用DDD的目標。正好相反，領域模型存在於BC內。在微服務架構實踐中，人們大量地使用了DDD中的概念和技術：
1.微服務中應該首先建立UL，然後再討論領域模型。
2.一個微服務最大不要超過一個BC，否則微服務內會存在有歧義的領域概念。
3.一個微服務最小不要小於一個聚合，否則會引入分散式事務的複雜度。
4.微服務的劃分過程類似於BC的劃分過程，每個微服務都有一個領域模型。
5.微服務間的集成可以通過Context Map來完成，比如ACL（Anticorruption Layer，防腐層）。
6.微服務間最好採用Domain Event（領域事件）來進行交互，使得微服務可以保持松耦合。
#DDD, Domain Driven Design, 領域, 驅動, 設計, 微服務
UL（Ubiquitous Language，通用語言）是團隊共用的語言，是DDD中最具威力的特性之一。不管你在團隊中的角色如何，只要你是團隊的一員，你都將使用UL。由於UL的重要性，所以需要讓每個概念在各自的上下文中是清晰無歧義的，於是DDD在戰略設計上提出了模式BC（Bounded Context，限界上下文）。UL和BC同時構成了DDD的兩大支柱，並且它們是相輔相成的，即UL都有其確定的上下文含義，而BC中的每個概念都有唯一的含義。
一個業務領域劃分成若干個BC，它們之間通過Context Map進行集成。BC是一個顯式的邊界，領域模型便存在於這個邊界之內。領域模型是關於某個特定業務領域的軟體模型。通常，領域模型通過物件模型來實現，這些物件同時包含了資料和行為，並且表達了準確的業務含義。
從廣義上來講，領域即是一個組織所做的事情以及其中所包含的一切，表示整個業務系統。由於“領域模型”包含了“領域”這個詞，我們可能會認為應該為整個業務系統創建一個單一的、內聚的和全功能式的模型。然而，這並不是我們使用DDD的目標。正好相反，領域模型存在於BC內。在微服務架構實踐中，人們大量地使用了DDD中的概念和技術：
1.微服務中應該首先建立UL，然後再討論領域模型。
2.一個微服務最大不要超過一個BC，否則微服務內會存在有歧義的領域概念。
3.一個微服務最小不要小於一個聚合，否則會引入分散式事務的複雜度。
4.微服務的劃分過程類似於BC的劃分過程，每個微服務都有一個領域模型。
5.微服務間的集成可以通過Context Map來完成，比如ACL（Anticorruption Layer，防腐層）。
6.微服務間最好採用Domain Event（領域事件）來進行交互，使得微服務可以保持松耦合。
領域驅動(Domain Driven)主要目的為軟體架構與數據模型的設定上要能更貼近業務需求，核心為強調提昇軟體設計品質的概念，例如把基礎建設如操作數據或組合型功能抽離成抽象層、針對介面來寫程式、大量使用依賴注入的技巧等，使軟體開發的關注點著重於領域的設計上，進而能減少開發、擴充與維護的成本。
#DDD, Domain Driven Design, 領域, 驅動, 設計, 微服務
留言
張貼留言