單個團隊的領域驅動設計

本篇詳細講述我在2021.10.30日，對于領域驅動設計的看法。

我認為所有事情是聯結在一起的，從洗漱時先刷牙還是先洗臉，到設計上先短期還是先長遠，直到實踐上細節抽象的争論。

先說結論，領域驅動設計(DDD,aka Domain Driven Design),是一個結果，而不是一個工具，它并不像Git那般，今日決定大家使用Git進行代碼管理，經過多日準備後，即可完成。作為一個結果，就要從結果的角度看待DDD,因為有了這個結果，得到了更優的開發效率，更好的開發品質，更低的開發成本。若抛棄DDD這個名詞，直接去追求這三個更好，也許會有另一種形态的結果。本質上DDD是一種容易形成的結果，這個結果是一種狀态，它沒有“完成”這個概念。

講這些，是要将讀者的目的，從“我如何得到DDD”,轉向“DDD到底做了些什麼，可以讓我抄一抄，進而接近甚至達到三個更好的狀态”。

開發是需求->設計->施工 這條線上混亂的飛線過程，我們已知的，無可辯駁的事實如下：

1.開發團隊内人員，無論是哪個崗位，從進入團隊開始上手，到穩住局面，需要時間，這個時間往往是很大的代價。

2.人員間的交流，從來是有損的，可以做到低損失率交流知識的人員，是稀缺資源。

3.“開發”這個事情本身是難以控制實質的，我們要效率，就會損失品質，得到的效率與損失的品質之間，不成正比。

4.“知識”的失傳往往造成嚴重後果，進度與難度的評估嚴重依賴知識。

而一般的開發團隊（典型的單個項目單個團隊）面臨外部壓力如下：

1.品質難以把控的需求（有些是提煉過的，有些是原始的，非常的看緣分）

2.平均能力相對較差的團隊（如果你認為現有團隊能力較強，說明你不應該是團隊負責人，真正有利可圖的開發，總是使用較差團隊完成較高難度項目，這個本質是利潤空間）

3.有限的工期（變動空間不大，屬不可抗力）

基于無可辯駁的事實與外部壓力，我們可以發現最大的風險來自于兩項：

1.内部知識管理不善導緻内部成本飙升

2.外部需求變動或不可抗力變動，導緻環境突變

總結這兩項風險，前者看起來我們可以做些什麼，後者看起來什麼都做不了，但其中關系需點出：如果内部知識管理水準較高，導緻内部成本低于行業均值，可提高抵抗外部變動風險的能力，也就本質上提高了整個項目盈利的期望。

最好的知識管理方式是什麼，我認為是獨裁。

作為中國人，我們基本都了解統一度量衡和語言後，帶來的大一統便利，大一統本質上是降低了知識流通的成本，想要儲存知識，必須降低其流通成本，必須進行統一，必須進行獨裁。故要做些什麼，必須先得到獨裁權力，那麼最好的，推動此事的負責人為項目經理或技術經理，或兩者的一緻行為（需一緻利益）。

我們假定這個獨裁者已經有了，團隊的資源可以任意調動，那麼相應的，為了管理好知識，需做到兩件事情：

1.降低知識本身的難度

　　對于知識的産出者，我們稱其為專家，一般是各路大佬，他們作為相關經驗持有者，其原始産出往往帶有較高的閱讀了解門檻。作為獨裁者，可要求其針對團隊現狀，給出簡單能用的解釋，以降低知識本身的了解難度。

2.統一知識交流的名詞體系

　　對于知識的使用者，我們稱其為知識消費者，一般是團隊内依賴他人成果進行工作的人員。作為獨裁者，可指定唯一的一份知識中心（實踐上，一般是一份詞彙解釋表，交代團隊内通用俚語）， 要求消費者使用知識中心來進行知識交流。

領域驅動設計中，“領域”指的一般是統一後的知識與持有這些知識的人，我們可以把它想象成一個市場，這個市場裡貨币是石頭，貨物是魚幹和樹皮，魚幹和樹皮的生産者與消費者自覺地進行貨物交換，市場得以正常運作，這個市場，即是一種領域；新的人員來到這個市場，他僅需閱讀市場規定（詞彙解釋表），即可開始行動。

領域形成後，至于“驅動設計”，便是自然而然的在詞彙表中新增一個詞彙，該詞彙需要全體人員的認同與了解（獨裁者有很多辦法），那麼驅動設計的本質是“領域”擴張。

以上講的比較簡單，但實踐上做知識統一和知識市場，是需要強人進行獨裁的，讀者需自行判斷自己的影響力是否足夠。

最好的抗風險方法是什麼，我認為是低成本。

這個很好了解，如果我的成本夠低，那麼成本沒了就沒了。

對齊到知識統一這個事情上，對于風險的抵抗主要來源于以下兩點：

1.内部的統一詞彙解釋表，可以多大程度的反映外部實際

2.内部的統一詞彙解釋表，可以多大程度的降低成本

這兩點往往是沖突的，一個不太反映實際的詞彙表，往往非常簡單，可以降低很多内部成本，但在實際變化時，死的很快。

那麼核心落實在詞彙解釋表的編纂上：

1.外部實際可能發生的變化，不會是無方向的（如果你看不到方向，請找對應行業的專業人士），務必要對外部變化進行一個方向預期，這個預期很容易準

2.詞彙解釋表需具有一定的複雜度，來增加邏輯豐富性，可針對性的向上一條的預期偏離

3.某些讓人糾結的名詞，如果它不影響整體的能跑，先砍掉（通常是體驗，性能之類的東西）

這就是解決問題的方式了。

總結起來，領域驅動設計的核心是知識管理，而知識管理的核心，是獨裁者的詞彙編纂工作，它也是内外統一的風險管理工作，如果能得到複雜度較低的且足夠貼合外部實際的詞彙解釋表，則可使得整個團隊獲得競争優勢。領域驅動設計使得開發團隊管理問題變為複雜度處理問題，講明白了上述的正向思路後，我們講講這個思路執行的風險點：

1.獨裁者能否得到實際權力（你别看名，權你到底有沒有

2.獨裁者個人能力問題（如果獨裁者能力顯著低于行業平均，則很難救場

3.團隊本身競争力問題（這套思路可以救回來一定的競争力，但不是神藥

4.你需要DDD嗎？（

一些開發團隊并不直接面臨市場無法考核其成效，不需要DDD

一些開發團隊項目極其簡單，不需要DDD

一些開發團隊其知識已經是行業通用的，不需要DDD（本質是領域知識已完備，無需建構詞彙解釋表）

補充-項目與團隊的關系

假如建構好了詞彙解釋表，已經花了不少成本，覺得很虧，怎麼辦。

對于項目：（進行到了即将上線，線上問題很多，項目成功隻差臨門一腳）的情況下，撕毀這個詞彙表，拿到收益

對于團隊：大家過慣了根據詞彙解釋表工作的日子，需堅持這個習慣，應對下一個項目