如果您是DDD的新手，並且不確定從哪裡開始，則此流程為您提供了逐步指南，幫助學習和實際應用域驅動設計的各個方面：從圍繞組織的業務模型定位到編碼域模型。

使用此流程將指導您完成設計具有DDD思維方式的軟體系統的每個基本步驟，因此您可以專注於業務挑戰，而不會因同時學習DDD而感到不知所措。

完成該過程的幾次迭代後，您將具有基礎的DDD理論和實踐經驗，可以更深入地研究DDD。然後，您將能夠適應和改進流程，以適應任何情況下的需求。在實際的專案中，您經常會在這些步驟之間來回跳動。

注意：

此過程適用於初學者。您不應將步驟標準化為最佳實踐。域驅動設計是一個進化的設計過程，需要在知識和設計的各個方面進行連續迭代。

 圖中步驟如下：

1. 對齊：業務模型對齊需求
2. 發現：對領域實現視覺化和協作
3. 解耦：將領域分為子域
4. 連線：將子域形成為一種鬆耦合架構
5. 戰略：專攻業務差異化的核心子域
6. 組織：按照有界上下文組織團隊
7. 定義：定義每個有界上下文的角色和職責
8. 編碼：使用戰術模式實現有界上下文

何時使用DDD Starter建模過程？

如果您不熟悉DDD，或者不確定從哪裡開始，那麼此過程可以減輕您的認知負擔。它將指導您完成以下方案，以及其他方案：

• 啟動新專案：在一個新專案開始時，您需要考慮的事情可能會令人不知所措。此過程的一兩次迭代可以幫助您奠定基礎。
• 開始舊專案遷移：在開始對遺留系統進行現代化之前，此過程的一些迭代可以幫助您發現為目標體系結構建立願景所需的基本資訊。
• 啟動主要工作計劃：當開始一項新計劃涉及許多團隊的重大投資時，必須涵蓋該過程中的8個步驟。此過程可以指導您完成前幾次迭代。
• 探索您的領域以獲得新的學習機會：軟體開發是一個學習過程。您可以隨時應用DDD Starter建模流程來發現新見解，發現新機會或在團隊中簡單地共享知識。
• 評估專案的當前狀態：此過程可以作為評估當前系統與域和業務模型的協調程度的基礎。
• 重組團隊：鬆散耦合的體系結構使團隊可以並行工作而不會受到阻礙。鬆散耦合的體系結構還必須與域中的耦合對齊。此過程將幫助您設計軟體體系結構以及與您的域保持一致的團隊結構。
• 練習或學習DDD：當您是DDD的新手並且想要練習時，或者您要教別人建模域的不同方面時，此過程非常理想。重要的是要傳達這一線性過程不是現實的過程。這只是減少認知負擔的起點，直到您對DDD充滿信心為止。

流程詳細

此過程由以下8個步驟組成：

1.對齊

使我們的重點與組織的業務模式，使用者的需求以及短期，中期和長期目標保持一致。

我們對體系結構，程式碼或組織所做的每個決定都會帶來業務後果。為了最有效地設計，構建和發展軟體系統，我們的決策需要創造最佳的業務影響，只有當我們與業務目標保持一致時才能實現。

設計不良的體系結構和/或邊界可能產生負面影響，甚至使實現這些目標變得不可能。

首先，我們建議使用“業務模型畫布”。

工具類

• 影響對映
• 商業模式畫布
• 產品策略畫布
• 沃德利製圖

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人
• 瞭解產品和業務策略的人

2.發現

通過視覺和協作發現域。這是DDD的最關鍵方面。您不能跳過發現。如果您的整個團隊對領域沒有很好的瞭解，那麼所有軟體決策都會被誤導。通過整個團隊傳播領域知識將建立共同的理解。它使開發人員能夠構建與該領域相對應的軟體系統，從而可以更加靈活地合併未來的業務變更。確保領域知識遍及整個團隊，使成員能夠為改進產品做出貢獻。

發現是連續的，成功使用DDD的團隊經常練習發現技術。總是有更多有關該域的知識。首次嘗試發現時，具有EventStorming等技術經驗的協調員可以幫助團隊從淺層次上發現發現的真正好處。

我們強烈建議您檢視Visual Collaboration Tools。

作為起點，我們建議使用EventStorming。

工具類

• 域講故事
• 範例對映
• 事件儲存
• 使用者旅程對映

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人
• 瞭解產品和業務策略的人
• 瞭解客戶需求和問題的人
• 真正的終端使用者

3.分解

將領域分解為子域-域的鬆散耦合部分。

出於以下幾個關鍵原因，我們將大問題域分解為子域：

• 減少了認知負擔，因此我們可以獨立地推理領域的各個部分，
• 給開發團隊自治權，以便他們可以在解決方案的各個部分工作，
• 識別域中的鬆散耦合和高內聚性，這會延續到我們的軟體架構和團隊結構中。

首先，我們建議將事件風暴劃分為子域和上下文對映。

工具類

• 業務能力建模
• 設計啟發式
• 帶有子域的事件儲存
• 獨立服務啟發式
• 使用上下文圖視覺化社會技術架構

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人

4.連線

將子域連線到一個鬆散耦合的體系結構中，該體系結構可以滿足端到端業務用例。

必須不僅將大的區域分解成多個部分，而且還必須仔細設計這些部分之間的互動，以最大程度地減少不必要的耦合和複雜性。有必要通過應用具體用例來揭露隱藏的複雜性來挑戰初始設計。

首先，我們建議您使用域訊息流建模。

工具類

• 業務流程模型和符號
• 域訊息流建模
• 流程建模事件儲存
• 順序圖

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人

5.制定戰略

從戰略上規劃您的子域，以識別核心域：該域中具有最大業務分化潛力或戰略意義的部分。

時間和資源是有限的，因此瞭解域的重點是提供最佳業務影響至關重要。

通過分析核心領域是什麼，您將更好地瞭解系統各部分的質量和嚴格程度，並且能夠做出受過良好教育的構建，購買還是外包決策。

首先，我們建議使用Core Domain Charts。

工具類

• 核心領域圖表
• 目的對齊模型
• 沃德利製圖

誰參與

• 瞭解產品和業務策略的人
• 設計，構建，測試軟體的人
• 有領域知識的人

6.組織

組織針對快速流程進行優化並與上下文邊界保持一致的自治團隊。

需要組織團隊以具有自主權，明確的目標和目標感。為此，我們需要考慮組織上的限制，以便團隊進行自我組織以實現快速流動。

團隊自我組織：組織不是對團隊進行的工作，而是團隊應參與定義其邊界，相互作用和職責的過程。

諸如Red Gate Software之類的一些公司授權並信任他們的團隊以充分組織自己。

如果使團隊與上下文邊界保持一致，我們可以優化人們之間的協作方式。為了確定團隊的規模，我們需要考慮可用的人才，認知負擔，溝通開銷和匯流排因素。

首先，我們建議使用Context Maps視覺化社會技術架構。

圖片來源：MichaelPlöd

工具類

• 動態補給
• 先鋒，定居者和城市規劃師
• 團隊拓撲
• 使用上下文圖視覺化社會技術架構

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人
• 瞭解產品和業務策略的人

7.定義

定義每個有限上下文的角色和職責。

在進行設計之前，請對選擇做出明確的決定，這些選擇可能會對整體設計產生重大影響。在仍然很容易改變主意並探索替代模型的同時，儘早進行這些對話。

進行協作和視覺化設計，並開始考慮技術限制，以便您可以發現制約因素或機遇。

首先，我們建議使用Bounded Context Canvas。

工具類

• 邊界上下文畫布
• C4系統上下文圖
• 質量風暴

誰參與

• 設計，構建，測試軟體的人
• 有領域知識的人
• 對產品負責的人

8.編碼

編碼實現領域模型。將程式碼與域對齊可使域更改時更輕鬆地更改程式碼。通過與專家協作對問題空間進行建模，開發人員有機會了解該領域並最大程度地減少誤解。

首先，我們建議使用“ 聚合設計畫布”。

工具類

• 總體設計畫布
• C4元件圖
• 設計級事件儲存
• 事件建模
• 六角建築
• 暴民程式設計
• 模型探索漩渦
• 洋蔥架構
• 統一建模語言

誰參與

• 設計，構建，測試軟體的人

詳細點選標題見Github專案