讀張逸的領域驅動設計之應對軟件複雜度筆記

    張逸的《領域驅動戰略設計實戰》地址，付費的，價格￥59，還能接受。

    Eric Evans認爲"不少應用程序最主要的複雜度並非技術上，而是來自域自己、用戶的活動或業務"。最終決定的因素仍是由於需求。

需求引發的軟件複雜度

    需求分爲業務需求和質量需求，於是需求引發的複雜度能夠爲倆個方面：技術複雜度與業務複雜度。

1.     技術複雜度來自於需求的質量屬性：諸如安全、高併發、高可用，爲軟件設計帶來了極大的挑戰。
2.     業務複雜度對應了客戶的業務需求：這種複雜度每每回隨着需求規模的增大而增長。

技術複雜度與業務複雜度並不是徹底獨立，兩者混合在一塊兒產生的化合做用更讓系統的複雜度變得不可預測，難以掌控。

當咱們面的一個相對複雜的軟件系統時，一般面臨的問題在於：

• 問題域過於龐大而複雜，使得從問題域中尋求解決方案的挑戰增長，該問題域軟件系統的規模有關。
• 開發人員將業務邏輯的複雜度與技術實現的複雜度混淆在一塊兒，該問題域軟件系統的結構有段。
• 隨着需求的增加和變化，沒法控制業務複雜度和技術複雜度，該問題與軟件系統的變化有關。

領域驅動設計的應對措施

    隔離業務複雜度與技術複雜度，要避免業務邏輯的複雜度與技術實現的複雜度混淆在一塊兒，首要任務就是肯定業務邏輯與技術實現的邊界，從而隔離各自的複雜度。領域驅動設計經過分層架構與六邊形架構來確保業務邏輯與技術實現的隔離。

分層架構的關注點分離：分層架構遵循了"關注點分離"原則，具體表如今，將屬於業務邏輯的關注點放在領域層(Domain Layer)中，而將支撐業務邏輯的技術實現放到基礎設施層。

六邊形架構的內外分離：目前還不是很理解，待深刻。

限界上下文的分而治之

        

更新中......