使用DDD的業務價值

如果你的經驗和我相當，你就應該知道軟件開發者不應該只是熱衷于技術，而是應該將眼界放得更寬。我認為不管使用什么技術，我們的目的都是提供業務價值。而如果我們采用的技術確實產生了業務價值，人們就沒有理由拒絕我們在技術上的建議。

如果我們提供的技術方案比其他方案更能夠產生業務價值，那么我們的業務能力也將增強。

業務價值最重要嗎？

當然啦，我甚至都在想是不是應該將“使用DDD的業務價值”這一節再往前放一些。更確切地講，該章節的題目叫“如何向你的老板推銷DDD”更為合適。我并不希望你將本書看作只是些理論，而是希望本書對你的公司具有實際的指導意義。

讓我們來看看DDD所帶來的一些非常理想化的業務價值。記得將這些分享給你的管理層、領域專家和技術人員。我們可以將DDD的業務價值大致總結為以下幾點：

1. 你獲得了一個非常有用的領域模型

2. 你的業務得到了更準確的定義和理解

3. 領域專家可以為軟件設計做出貢獻

4. 更好的用戶體驗

5. 清晰的模型邊界

6. 更好的企業架構

7. 敏捷、迭代式和持續建模

8. 使用戰略和戰術新工具

1. 你獲得了一個非常有用的領域模型

DDD強調將精力花在對業務最有價值的東西上。我們并不過度建模，而是關注業務的核心域。有些模型是用來支撐核心域的，它們同樣是重要的。但是，這些起支撐作用的模型在優先級上沒有核心域高。

當我們將關注點放在自己的業務和別人業務的區別上時，我們便能更好地理解自己的任務所在，同時我們將更具競爭優勢。

2.你的業務得到了更準確的定義和理解

業務人士能夠更好地理解業務本身。我甚至聽說通用語言曾經出現在某些公司的市場營銷材料中。

隨著業務模型的不斷改善，人們對業務的理解也將更加深刻。在團隊討論的過程中，一些業務細節被不斷地暴露出來，這些細節有助于掌握業務價值。

3.領域專家可以為軟件設計做出貢獻

當人們對自己的核心業務有了更深的了解時，業務價值自然就出來了。領域專家并不總是同意某些概念和術語。有時，分歧源自于領域專家們在其他公司工作時所積累起來的經驗，而有時分歧則源自于公司內部。不管如何，當領域專家們在一起工作時，他們最終將達成一致意見，這對于整個公司來說都是件好事。

開發者和領域專家共享同一套交流語言，領域專家將知識傳遞給開發者。開發者總是會離開的，有可能去接觸一個新的核心域，也有可能跳槽到其他公司，這時培訓和工作移交也將變得更加簡單，而“只有少數人才了解模型”的情況將大大減少。領域專家、剩下的開發者和新進人員可以繼續使用通用語言進行交流。

4.更好的用戶體驗

用戶體驗可以更好地反映出領域模型的好壞。

如果軟件留下太多的地方讓用戶自己去理解，用戶往往需要經過培訓才能做出操作決定。實際上，用戶只是將他們所理解的轉移到表單（form）中的數據而已。數據將被存儲起來，如果用戶不知道數據的用途，那么結果也將是錯誤的。

當用戶體驗是按照領域專家心中的模型來設計時，就不會出現以上的問題了。這時軟件本身便能對用戶起到培訓作用，而不需要業務人員來提供培訓。效率提高了，培訓減少了——這就是業務價值。

接下來我們看看技術為業務創造的價值。

5.清晰的模型邊界

我們并不鼓勵技術團隊將精力單純地放在編碼和算法上，而是期望他們能夠面向業務。明確的目標產生高效的解決方案，而要達到這樣的目的往往需要更好地理解項目的限界上下文。

6.更好的企業架構

一旦限界上下文得到了較好的理解和仔細的劃分，那么團隊的所有成員應該知道限界上下文間的集成是必要的。上下文之間的邊界和關系是明晰的。當不同上下文的模型間存在依賴關系時，我們將使用上下文映射圖來集成不同的限界上下文，而這又有助于我們全面地了解整個企業的架構。

7.敏捷、迭代式和持續建模

“設計”這個詞可能并不能取悅業務管理層。然而，DDD并不是一個重量級的設計方法和開發過程。DDD并不是畫模型圖，而是將領域專家的思維模型轉化成有用的業務模型。DDD不是創建一個真實世界的模型，而是模仿現實。

團隊的工作遵循敏捷方法——迭代式的，增量式的。任何一種敏捷方法，只要團隊認為合適，都可以用于DDD項目。通過DDD創建出來的模型便是可工作的軟件。團隊會對模型做持續的改進，直到業務層沒有新的需求為止。

8.使用戰略和戰術新工具

限界上下文為團隊創建了一個建模邊界，成員在邊界內部為特定的業務領域創建解決方案。在單個限界上下文中團隊成員共享一套通用語言。不同的團隊有時各自負責一個限界上下文，此時可以使用上下文映射圖在戰略層面上對限界上下文進行界分和集成。在某個建模邊界內部，團隊將使用戰術建模工具：聚合（Aggregate，10）、實體（Entity，5）、值對象（Value Object，6）、領域服務（Domain Service，7）和領域事件（Domain Event，8）等。