虛構的案例，真實的實踐

當我在考慮如何以最好的方式向讀者展示現代DDD的實踐指導時，我希望對每個知識點都做周到的解釋。這意味著我不但需要解釋“怎么做”，還需要解釋“為什么這么做”。通過案例研究，我可以闡述為什么我會給出這樣那樣的建議，以及DDD是如何解決我們日常遇到的困難的。

有時，我們可以了解一下其他團隊所面臨的問題和他們在DDD上所犯的錯誤，而這比單純地講解DDD更加容易。通過學習別人的經驗教訓，我們可以對自己做出評判，避開潛在的錯誤，向著正確的方向邁進。

我并不打算以我曾經工作過的實際項目作為本書案例（當然這也是我不能公開討論的），而是采用一個虛構的案例，但是里面卻包含了真實的經驗和實踐。在這個虛構案例中，我將展示實現DDD的最好方式及其原因。

在這個虛構的案例中是一個虛構的公司，公司里有一個虛構的開發團隊，他們有真實的業務章程，并且有一個真實的軟件系統需要開發部署，而他們所面臨的DDD挑戰和問題也是真實存在的。我發現這種案例是很有效的，同時我也希望你能從中獲益。

在這個團隊進行開發的不同階段，我們將看到他們所面臨的種種問題，同時我們還將看到他們是如何解決這些問題并且逐步走向成功的。該團隊所開發核心域的復雜性對于講解DDD是足夠的。另外，不同限界上下文之間存在依賴關系，這將有助于我們學習限界上下文的集成。然而，其中的三個示例模型并不能覆蓋到DDD戰略設計的各個方面。我并不刻意回避那些看似不相關的地方，而是在有必要給出建議的時候就給出建議。

那么現在，請允許我介紹這家虛構的公司，它的團隊和軟件項目。

SaaSOvation，它的產品和對DDD的使用

這個公司叫做SaaSOvation。正如它的名字所暗示，該公司旨在開發一系列SaaS（Software as a Service，軟件即服務）產品，這些產品作為一種服務被訂閱用戶使用。公司計劃先后開發兩套產品。

旗艦產品名為CollabOvation，這是一套企業協作（collaboration）軟件，并且加入了社交網絡的功能。該產品的功能包括論壇（forum）、共享日歷（shared calendar）、博客（blog）、即時消息（instant message）、wiki、留言板（message board）、文檔管理（document management）、通知（announcement）和提醒（alert）、活動跟蹤（activity tracking）和RSS等。所有的這些協作工具都旨在滿足企業業務的需求，幫助他們在項目中提高工作效率。在這個經濟步伐不斷加快的時代里，業務協作對于企業氛圍的營造起著重要的作用。任何有助于提高生產率、鼓勵知識分享和增進團隊協作的實踐都是企業成功的促成因素。

CollabOvation希望給客戶帶來有價值的產品；而對于開發者，他們所面對的挑戰也是富有意義的。

第二套產品名為ProjectOvation，這是該公司的開發團隊主要關注的核心域。ProjectOcation主要用于敏捷項目的管理，使用Scrum作為項目管理方式，并且采用增量式的管理框架。該產品采用傳統的Scrum項目管理模型，其中包括產品（product）、產品負責人（product owner）、團隊（team）、待定項（backlog item）、計劃發布（planned release）和沖刺（sprint）。對待定項的評估通過對業務價值的分析來確定。

CollabOvation和ProjectOvation并不是兩套互不相關的產品。SaasOvation公司非常看重敏捷軟件開發過程中的團隊協作。因此，CollabOvation可以作為ProjectOvation的增值服務。毫無疑問，在項目計劃和團隊討論中使用協作工具將是一個不錯的選擇。SaasOvation公司預測，60%的ProjectOvation用戶將使用CollabOvation所提供的功能，這將在很大程度上增加CollabOvation的銷量。一旦建立起了銷售渠道，而用戶團隊也意識到了協作工具的好處，他們很有可能購買整套CollabOvation產品。基于此，SaasOvation公司進一步做出預測，至少35%的ProjectOvation用戶會全面使用CollabOvation，這還只是一個很保守的預測。

首先啟動的項目是CollabOvation。該團隊中有為數不多的幾個“老兵”，但大量的是些中級開發人員。在項目組的早期會議中，他們決定采用DDD。其中一個高級開發者在他上家公司中使用過非常有限的DDD。在他談到自己DDD經驗之后，我們可以看出他并沒有全面地使用DDD，他使用的其實是DDD-Lite。

DDD-Lite是DDD戰術模式的一個子集，它并不強調對通用語言的使用。此外，DDD-Lite通常也忽略了限界上下文和上下文映射圖。更多的，DDD-Lite是關于技術實現層面的，雖然這也是有好處的，但是好處并沒有與DDD戰略模式一同使用時那么大。SaaSOvation決定采用DDD-Lite，然而不久之后他們就遇到問題了，因為他們并不了解子域和限界上下文。

更糟糕的是，SaaSOvation雖然避開了DDD-Lite的陷阱，但這純屬僥幸，因為他們的兩套核心產品自然地形成了各自的限界上下文。這也使得CollabOvation模型和ProjectOvation模型得到了正式地分離，但是這也是偶然的，并不意味著團隊就是了解限界上下文的，而這也是為什么該團隊在一開始就遇到了問題的原因。不學就得落后啊。

通過調查SaaSOvation對DDD的不完整使用，我們可以學到很多。該團隊從他們所犯的錯誤中學到了如何使用DDD的戰略設計。同時，我們還可以從CollabOvation團隊所做的修改調整中受益匪淺。前人栽樹，后人乘涼，之后的ProjectOvation團隊也從CollabOvation的回顧會議中學到不少。完整的故事，請參考子域（2）、限界上下文（2）和上下文映射圖（3）。