本文書接上回《這就是為什麼你學不會DDD》，關注公眾號（老肖想當外語大佬）獲取資訊：
- 最新文章更新；
- DDD框架原始碼（.NET、Java雙平臺）；
- 加群暢聊，建模分析、技術實現交流；
- 影片和直播在B站。
https://mp.weixin.qq.com/s/TJEtclwcJydiE58pjWpXXw
背景
前文說到，我們在建模的時候要放下技術層面的心智負擔，這是我們自己內在的問題，相對來講容易克服。但另外一面，我們分析需求、設計模型時候，就會與業務人員、產品經理等角色進行深入溝通互動，這個時候，很難找到一個比較一致的表述方式，以在大家的大腦中展現出比較一致的形象，往往會出現認知偏差，甚至相互得出相反的理解卻無法察覺的情況，溝通效率和準確性非常糟糕。
為了解決這個問題，我們發現了一個很容易被接受的“類比”，就是“擬人化模型溝通法”。
PS： 你依然要先忘掉所有的技術知識。
為什麼可以擬人化
我們先來看下面的圖，展示了一家公司的組織架構：
如果我們把圖中的結構不變，僅僅是把元素的名稱進行替換，就能得到一個系統的結構圖：
在這裡我們得到如下的對應關係：
其中公司對應系統，部門對應模組，可以理解為層級或者分組，是比較自然的，接下來我們重點看看員工和模型為什麼可以對應。
“人”與“模型”的共性
首先我們思考一下，企業中員工之間是怎麼協作的，我覺得無外乎下面兩種情形：
- 真“手把手”教你做事；
- 我做好我的事，然後通知你，你做好你的事；
類似下圖：
如果一個任務需要員工A手把手教員工B做，那是不是意味著下面幾個情況：
- 員工B無法獨立完成該任務；
- 員工A對該任務最終負責，或者至少是AB共同負責；
如果兩個員工的協作模式模式2，即“我做好我的事，然後通知你，你做好你的事”，是不是意味著：
- 員工A和員工B各自有自己的職責；
- 員工A和員工B透過“通知（事件）”來協作；
基於上述的邏輯，我們是不是可以得出下面的類比：
基於這樣的類比，我們可以得出如下結論：
- 如果一個任務需要模型A直接依賴（呼叫）模型B，說明它們無法獨自完成任務；
- 如果模型A和模型B僅透過事件協作，說明它們相互獨立，職責邊界清晰；
這個結論情形2是非常合理的，但如果我們遇到的是情形1，一個任務需要模型A和模型B共同的資訊協作才能完成，我們一般認為有兩個可選方案：
- 合併模型A和模型B，把他們看作一個整體，在模型圖上的表現，就是他們之間有實線相連，他們是一個聚合整體；
- 建立模型C，來負責這個任務的解決，由模型A和模型B透過事件通知的方式把資訊告訴模型C；
最終我們的模型都會是透過事件的方式協作，“人”與“模型”的共性大體如下：
- “人”與“模型”都有自己的職責，負責解決特定的業務問題；
- “人”與“模型”都擁有要履行自己職責所需要的資訊；
- “人”與“模型”都透過事件驅動來協作；
擬人化建模溝通法
基於上面的推導，我們可以把一個個“模型”看作是一個個人的名字，那麼在我們溝通時，就會可以用擬人化的方式來表達業務流程，表達模型的職責，表達模型身上需要攜帶哪些資訊，表達命令與事件：
- 當“支付單”支付成功的時候，“訂單”得把自己的支付狀態設定成已支付；
- 當“使用者”註冊成功的時候，得向“使用者積分賬戶”裡發5個積分；
- “商品列表”要展示“商品資訊”和“銷售統計”的綜合資訊，還得支援各種緯度的搜尋，效能還得跟得上；
透過擬人化的方式，我們可以在業務人員、產品經理、技術人員的大腦中構建比較一致的形象，這些形象對應著“職責”、“能力”和“邊界”，從而我們可以在一個頻道上推演這些“模型”的定義和分工協作，是否真的可以滿足需求，至此，我們的團隊獲得了一個能力，就是“有效的建模溝通”，藉助這個能力，我們就可以實現“需求-模型-程式碼”三者一致性的前半部分，即“需求-模型”的一致性：
後續
後續，我們會就“模型-程式碼”如何保持一致性展開剖析，敬請期待。
請關注公眾號（老肖想當外語大佬）獲取最新更新。