領域驅動設計（Domain Driven Design)
經歷過公司一套混亂的技術體系以後，今年初開始重構系統，現記錄這一路的感受和體驗並總結經驗。
歷程:公司擁有三套主業務系統，採用了六套技術體系(服務器端四套，前端兩套)，涉及多個語言，每次要修改維護的時候都是對體力、時間、精力非常大的消耗，而且最終效果也不盡人意，總結下來問題主要出現在語言不統一(當然不止程序語言，還有交流時對某個概念，名詞和認知的統一),需求不明確主流程變更太頻繁(架構體系太多太複雜對明確的需求依賴度非常大)
爲了破局第一是將技術複雜度和業務複雜度獨立開，第二通一語言，因爲大家都使用統一的一套通用語言，所以溝通成本會大大減小，不會在討論A的時候以爲是B，第三抓好需求評審關口，第四開發過程中面向領域，面向領域去開發產品有助於我們深入分析產品的內在邏輯，專注於解決當前產品的核心問題，而不是冗餘的做很多功能模塊，或者現場操作人員反饋的問題就去更改產品邏輯，完了上線後用戶不用，你還在那邊罵現場人員朝三暮四，亂提需求。
正文：
業務開發大致分爲一下幾個階段 需求評審-->技術評審-->測試評審-->開發-->上線後迭代
需求評審
系統設計難以擴展的很大原因就在於需求的不完整。設想一個很大的需求場景，你拿到的只是部分，你設計出來的系統能夠滿足後來的擴展麼？
DDD 強調的有：
需求不要僅僅侷限於需求文檔，要多多聯想生活，個人工作經驗，多想想競品的實現。
不確定的細節多討論，對象不一定是產品經理，重點是對業務的廣度和深度理解比較強的人。
這兩點非常重要，做出產品後結果可能是你得到了 10 個場景，但需求文章只做其中的 2 個場景，但剩下的 8 個場景沒有浪費，可以爲你的系統設計做好擴展，因爲你清楚，以後這裏可能會改。
至於如何擴展，核心在於抽象，你可以把共用的事情抽象，可以把行爲抽象，可以把流程抽象等。
需求評審主要目的是爲了弄懂業務和需求，當然弄懂業務和需求是什麼很難，有可能你專注於這個業務幾年後，才能真正知道該如何定義這個業務，所以我們該把這個目標縮小一下。
於是一般的評審會，很多時候就去聽聽流程，聽聽我們要做成什麼樣子。
DDD 更加強調業務的本質，最後達到能用一兩句話直白地把業務描述出來的效果
需求評審的產出最後結果就是需求文檔
當然需求文檔出來後最好是有一篇最初版的通用語言出來（一定上下文內，對業務概念的一致通用表達，是理清業務是什麼，能幹什麼，以及和其他業務邊界的過程）當然這個是理想狀態因爲產品經理大多不會願意做這種事情，所以需要開發人員自己整理（時間如果不夠也最好能有一個簡要版本）,
技術評審
技術評審應該產生三個結果：通用語言，領域模型，數據模型
通用語言已經提了，現在是領域模型
領域模型是領域驅動設計中最重要的最複雜的地方也是最耗時間的地方,當然最好是在需求評審的時候就開始準備
領域模型用來定義領域元素，和管理領域元素的上下文的。
常見的領域元素有：實體、值對象、聚合、領域服務、應用服務、領域能力等。
領域元素之間的上下文指：元素間包含關係和邏輯關係。
數據模型
數據模型，就是在領域模型的基礎上進行建表，我們需要表達出一種存儲結構
當通用語言、領域模型、數據模型都準備好了之後，當然我們這裏準備的只是初版，我們在技術評審會上，需要把團隊成員都叫上，由開發主導，向各個成員展示我們的初版成果，大家可以一起討論，有爭議的地方，討論出結果後，再修改掉。
測試評審
測試評審會的主導者是測試工程師，開發和產品需要注意的有：
測試工程師的表達是否符合通用語言，不符合請糾正。
測試工程師的理解是否和你理解一致，不一致請討論。
以上階段完成，DDD 戰略設計也基本完成了。
其實和普通的設計流程差別一致的，但思想側重點不一樣，DDD 更加側重於如何想清楚業務是什麼、能幹什麼、邊界在那裏，戰略設計的所有產出都是圍繞着這三個問題展開的。
準備睡覺後面準備開始些戰略設計