本文書接上回 《關於領域驅動設計，大家都理解錯了》
歡迎關注公眾號“老肖想當外語大佬”： https://mp.weixin.qq.com/s/HHJ5vt2_iT0-CFcw0HcPnA
先有雞還是先有蛋的困局
前文我們提出了“領域驅動設計是一種價值觀”這個觀點，那麼落地領域驅動設計就是踐行價值觀的過程，實踐過程中勢必需要一些方法來指導，那麼問題來了，一個團隊要落地領域驅動設計，是先有認知還是先有方法呢？
如果團隊沒有“識別範圍和邊界是最重要的事”這樣的認知，那麼大機率也不會關注它，“方法”就無從談起，如果沒有“方法”，你大機率也體會不到“識別範圍和邊界是最重要的事”這樣價值觀帶來的好處，那麼就很難構建起這樣的價值觀，因此就陷入了一個“先有雞還是先有蛋”的困局，這也是現實中大多數研發團隊面臨的困局，即使團隊中有人意識到這個問題，普遍地也是無能為力。
核心問題是什麼？
你可以審視一下自己的團隊，在需求分析的時候，是否真的建立了需求邊界的共識？產品經理在定義產品功能的時候，又是否真的把功能的邊界、目的、以及對應的需求給團隊講明白了？再看看你的程式碼，是否每個類的職責和目的都是清晰的？
如果以上問題的答案都是肯定的，那麼，你也不會覺得需求難分析、功能難設計、程式碼難修改了。我相信，大部分團隊的答案，都是“否”，而且這些問題，最後都會以程式設計師揹負著“迭代交付效率低下”這口大鍋，然後拼命用加班來補償而告終，然而這個鍋的罪魁禍首卻在立項的那一刻已經埋下了，很多的隱性代價在專案初期被忽視，無邊界的問題、模糊的需求、湊合的建模、背離現實的擴充套件性設計、匱乏的測試用例等等一系列的不確定性，在團隊的工作流程裡一步步被放大，而這個鍋該不該由流程下游才介入的程式設計師們來背，是值得商榷的。但組織的管理者並沒有這個認知，沒有這個判斷力，他們只會看到工期緊任務重，程式設計師們出活慢。
那麼問題來了，一個事情做不好，是決策者的鍋大，還是執行者的鍋大呢？
決策者是最大的絆腳石
在我看來，最大的鍋應該是團隊決策者的，首先，這一系列的問題本質就是沒有意識到“把問題的邊界和範圍搞清楚”是最重要的事，下達的很多決策都是脫離實際的。
“團隊成員無法推動團隊價值觀的變化”，這是因為價值觀的現實體現，就是決策結果，而團隊的決策其實是由管理者最終拍板的，因此管理者的價值觀就是團隊價值觀。
設想一下，假如老闆不期望員工加班，員工大機率不用加班，反之結果，就是普遍意義上的各種996、福報、奮鬥逼。老闆的價值觀，就是企業的價值觀，因為各種決策是老闆做的，決策本身就是價值觀的體現。放到研發團隊裡，團隊主管就是那個下決策的人，誠然很多經驗豐富的開發者、架構師對於軟體設計有豐富的經驗和獨到的見解，仍然架不住領導一句“明天這個功能就得上線”、“客戶要得急”、“先上線再說”。
所以我的觀點是：
- 決策者在做決策時，核心價值判斷出現了偏差；
- 決策者對自己的決策後果，缺乏充分的判斷力；
所以，決策者是領域驅動設計落地最大的絆腳石。
落地領域驅動設計的必要條件
要成功在團隊中實踐“領域驅動設計價值觀”，就必須把識別和明確邊界作為首要決策依據，那麼需要做到下面幾點：
- 所有的需求都有明確的邊界定義
- 所有的功能設計都有明確的邊界定義
- 所有的業務模型都有明確的邊界定義
- 所有的程式碼都有明確的邊界定義
而要做到這些，就必須由決策者直接或者授權團隊在這些問題上做充分的溝通和討論，所做的決定必須是明確的，哪怕是有限資訊下的決策，也得明確有多少是確定的，有多少是團隊建立了一個猜的共識，這些決策都明確的情況下，團隊的最終執行，就一定是符合領域驅動設計價值觀的。
此外，如果有下面兩條，那麼團隊落地領域驅動設計的順暢程度會大大提高：
- 一套匹配的DDD戰術框架
- 一組執行力強的開發團隊
這兩條，我們在後續更具體實戰操作中更詳細地展開和說明。
關鍵角色的能力模型
既然，決策者是最關鍵的角色，那麼這個角色需要具備哪些能力呢？
首先，決策者的核心職責如下：
- 理解業務與需求
- 業務建模
- 確保研發按照模型交付
具象化出來就是“業務專家的話你聽得懂”、“產品經理懂的你得懂”、“研發的方案你看得懂”，這個角色需要能夠與各個角色充分地交流和協作，並且對技術有充分的瞭解，那麼就必須有足夠的“判斷力”、“表達力”、“協作力”以及“技術功底”。
有這些能力做支撐，才能夠在溝通互動中捕捉關鍵資訊，識別問題的邊界，給出匹配的方案，才能判斷一個決策的範圍和邊界是否足夠明確，是否在團隊中建立了共識，是否明確了不可共識的部分。
改變的起點是相信“相信的力量”
在回到文章開頭，要打破“先有雞還是先有蛋”這個困局，需要團隊管理者身上突破，管理者得先意識到，問題的邊界、解決方案的邊界的重要性，先理解系統迭代慢這件事背後的核心因素就是在決策時把很多需要明確的問題推遲了，這個推遲，導致了團隊付出大量額外的代價來補償，以應對決策時的不確定性，偽需求、沒人用的功能、無意義的擴充套件性等等問題都是在一個個決策中產生的，而大家看到最終的結果，就是研發團隊的效率低下，一個小小的功能都迭代不上去，這個鍋扣在程式設計師身上是不符合事實的。
因此，要做出改變，先要相信“相信的力量”，你看到了這篇文章，嘗試理解了“範圍和邊界是最重要的事”這樣的價值觀，那麼接下來就是不斷地在每次決策和討論中實踐它，不斷自我審視自己的決策，是否把範圍和邊界弄清楚了，儘可能地向這個方向靠攏，我也相信，因為你的相信，一定能夠收穫到“相信”的價值。
不是決策者，我該怎麼辦
如果你不是決策者，而你又認同“領域驅動設計是一種價值觀”，那麼你有三個選擇：
- 將這個觀點與你的領導溝通，嘗試推動領導與你建立共識，獲取信任並幫助團隊做決策；
- 努力自己成為決策者；
- 以上都行不通，也許你該換個更加開放組織了；
後續
到此，領域驅動設計的概念和核心落地的核心角色已經描述完畢，期待與大家對這些觀點來討論溝通。
接下來，將展開探討作為領域驅動設計的核心角色，具體應該如何操作，幫助團隊將這個價值觀內化到日常工作行為中來。