DDD經驗：分享工作，分享決策 – Jessitron

為了一起改變軟體，我們需要一個共同的理解
在軟體團隊中，每個正在更改軟體或決定如何更改軟體的人都需要對軟體的作用、方式和物件的共同理解做出貢獻。（這個原則出現在領域驅動設計中。）

這方面的一個例子：架構建議流程。在這裡，軟體團隊需要邀請架構師來評論，他們維護組織系統的整體檢視。他們不必遵循這些架構師的建議，但他們必須考慮架構師所知道的一致性和更大的方向。
舊式架構師教條主義法令是：“這是我的系統如何工作的模型。實施！” 或者架構審查委員會：“不要做錯任何事”，這樣反而導致什麼都不做。

商業的一個例子：
有一天，在我朋友工作的醫院裡，行政部門釋出了一份關於使用N95口罩的建議，有三頁的單行本規則和豁免。
無法理解的是：他們要求數以百計的人把這些東西記在腦子裡，並根據這些規則做出日常決定。
這在認知上是昂貴的，也是貶低的。

如果行政部門轉而應釋出幾個要點來讓人們瞭解：

• 我們有足夠的口罩，讓與病人接觸的護士每天使用一個新的口罩。
• 護士們知道如何正確佩戴N95口罩；沒有經過這種培訓的人不會受益。
• 鬍子會妨礙正確的口罩密封，所以普通口罩也一樣好。
• 與病人或公眾接觸需要佩戴N95，而內部辦公室工作則不需要。

將你的心智模式強加給別人是一種權力的表達
要求其他人採用你的心理模式是一種權力的動態。
我們是在這種情況下長大的：在學校裡，我們被教導一種世界的模式。吸收它，學會這樣思考，把答案吐出來。(這是有道理的，當這個模型是幾千年工作的結晶。但這部分並沒有教我們如何共同思考）。

然後，當我們長大後，自然而然地就會轉移到這種權力動態的另一邊："現在我是決定正確的心理模型的人！"

軟體要求我們做得更好。我們已經看到這種高度現代主義的 "一目瞭然 "的做法一次又一次地失敗。

改變軟體需要在成千上萬的情況下做出成千上萬的決定。
決策必須是本地化的。我們不是透過把決定往上推，而是透過傳遞資訊來獲得更好的結果。

共享的理解不是來自於 "我分享我的理解，你採用它"，而是來自於 "我分享我的知識，你分享你的知識，我們一起構建一個新的理解"。

我們透過形成共同的（重疊的）理解來獲得更好的決定。我們透過改變軟體的每個人的參與來做到這一點。
我丈夫有一句老話。"你可以告訴我做什麼或怎麼做，但不能同時告訴我這兩個"。
正如：你可以要求我在行動和決策方面進行合作，或者你可以做出所有的決定，我可以選擇加入或退出（可能是退出）。

"不要做錯 "等同於 "不要做"。

我們沒有接受過參與知識增長的訓練，在學校裡沒有。我們在遊戲中，在假裝或捉迷藏的遊戲中做到了這一點。

打破 "我行我素 "的權力動態，進入增長共同理解的包容性，是一條通往更好的軟體和更好的生活的道路。