搭建中臺缺少方法論或者實踐？
系統開發者最終的實現與產品設計常常出現偏差？
系統開發者帶着產品在跑設計？
每個開發者對業務理解不同，實現不同，在人員交替的時候代碼邏輯分支太多？
項目干係人溝通缺少共同的語義，理解不一致？
那期待您共同參與到MDD架構實踐
**
一 尼式三原則
**
- 唯一原則
所有業務圍繞核心業務展開，並且核心業務是唯一的。如果核心業務不唯一，業務所在的系統需要進行拆分，直至唯一，拆分後的每個子系統存在僅存在唯一的核心業務流。
- 隔斷原則
核心業務代碼的組成單位是模塊。隔斷性表現在垂直隔斷和水平隔斷。
一核心業務主要基於模塊而非其他業務或者更基礎的業務單元代碼；
二模塊是業務隔斷的，模塊的邊界與業務劃分不重合甚至是業務近似無關的，如果在概念上可以抽象成業務無關名詞，其實更合適。
- 串連原則
模塊之間唯一的關係是抽象模型。隔斷原則使業務代碼依賴的模塊散落乃至沒有業務意義，如何串聯呢？或者如何使得模塊的編排和組合實現核心的業務邏輯呢，答案就是抽象模型。
通過場景串聯使得模塊成爲抽象模型的模塊。
**
二 3V 模型
**
3V 模型
3V 模型描述了三個原則在每個階段的適用場景。
第一步 系統整體建設階段，使用核心原則抽取出業務核心，初步劃分系統。拆分出核心系統。核心系統對應的核心業務流進行抽象，形成多個獨立的抽象模塊，結合場景進行模塊的場景串連，主要串連主業務場景，考慮周邊場景的合理性最終形成抽象模型。該階段的反彈，最終的抽象模型會反饋至模塊，模塊需要進一步拆分或者聚合。使用反彈階段的模塊產物來組織周邊系統的建設。這個階段是系統的遞歸分析；
第二步 系統內部建設階段，使用核心原則抽取出關鍵的領域核心，在第一階段生成的模塊產物需要和領域進行關聯，這種關聯性是領域中模型基本屬性的關聯，非業務性強關聯。該階段的底部及使用關聯了基本屬性的模型進行領域模型生命週期的串連。這個階段是子系統的遞歸實現。
第三步 功能完成建設階段，以第二階段生成的模塊產物爲基本代碼組織核心的功能，需要補充逐漸增強的業務邏輯代碼，主要是在粘合模塊產物而非重新定義邏輯。檢驗的標準是可以串連完整的業務功能。這個階段是功能的遞歸實現。
三個步驟中落實“尼式三原則“，在兩個不同維度（系統間和系統內）進行遞歸式分析和實現，最終收斂於模塊，理想的狀態就是業務邏輯的模塊化，這與隔離原則契合，使得整個系統業務邏輯模塊化取代模塊代碼是業務的，零散的。
九點圖
九點圖描述了層級依賴的關係，依賴的關係在3V模型中有已體現。模型層是抽象模型和模型模塊的整合層。領域層是與DDD實踐時的層次結構。業務層也是一般的應用層概念。
隔斷原則維護了模塊的高內聚，模塊需滿足開閉原則，保持對擴展的開放；串連原則保證了低耦合，使得業務模型和抽象模型是唯一映射的關係，而非模塊或者具體的業務代碼，這也是唯一原則的另一層面體現。
非核心業務代碼可以滿足隔斷原則，也可以不滿足。從核心業務到非核心業務，從核心模塊到非核心模塊可能存在隔離性的衰減。
再總結一下唯一原則，一個系統對應一個核心業務流，也對應一個完整的抽象模型。以上原則可以做到在圍繞核心業務，做到似斷非斷，在該斷的時候斷，不該斷的時候相連。
**
三 職能劃分
**
九點半圖
抽象模型是開發與產品之間的溝通語言，也限定了項目干係人溝通的共同語義。通過抽象模型保持項目組內的理解的統一性，在達成一致後，該層是最穩定的。模型模塊是不能職能的開發人員的溝通語言和工作關聯。業務邏輯基於模塊的組合編排，靈活性最高。
當業務需求變化時，
| 業務需求變化影響範圍 | 參與人員 |
|---|---|
| 影響到業務邏輯變化 | 產品+具體實現人員 |
| 影響到模型模塊 | +技術負責 |
| 影響到抽象模型時 | +架構師 |
當需求變化影響到抽象模型時需要架構師的配合，如變化範圍較大，需要重新規劃版本。項目的干係人職能約定在以上範圍內，層層保證業務設計與技術實現的匹配。
**
四 MDD 與 DDD 的關係與不同
**
相同：MDD 是DDD 設計方法的延申，特別是DCI 架構的接近，M是C的替代和演進。領域模型是領域驅動設計的核心，而在MDD中，Modeling（Module） 是設計的核心。這種改進解決了貧血模型和富血模型的衝突，同時支持DDD的三分層結構和傳統的四層代碼分層結構。
不同：MDD 提供原則和方法論的描述，可以與DDD 的相融相生，也可以指導傳統的架構設計方法。
**
五 交流
**
如果實踐成功，歡迎交流；如果發現掣肘，歡迎拍磚。
