寫在前面

個人認知水平有限, 能夠獲得別人的指正是一件很高興的事

遇到的問題

傳遞 "知識" 是一件難事, 傳達 "正確的知識" 是一件更加困難的事
在組織中傳遞知識, 對於工程師而言, 靜態的方式大概有兩種: 技術文件, 程式碼

問題一: 技術文件怎麼寫比較好?

期望達成的目標
不同面向進行描述的同時, 又能夠有可遵循的框架來撰寫技術文件, 讓整個不同時期的團隊能夠共同維護?

撰寫技術文件時, 發現還蠻常遇到這種情形: 對於同一個業務流程, 作者 B 和作者 A 切入的角度不同, 可能最後會看到兩份文件, 其中 80% 內容其實在講同樣的概念, 只有 20% 內容不同, 同時有的資訊已經過時, 如果沒有即時更新到, 對老人來說可能沒有影響, 他知道過去的歷史, 他有能力分辨出來, 但對之後來的新人就沒有這個知識儲備來判斷

問題二: 如何有系統地統一溝通語言?

命名是計算機領域的三大難題之一, 每個人對於命名都有自己的想法和取捨, 同樣的業務, 不同的系統, 不同的工程師, 使用的名稱可能也不同

只是如果對於描述同樣的業務流程, 不同的人使用不同的名稱來描述, 對於認知會是一個不小的負擔, 並且也容易在修改時發生意想不到的錯誤(漏改或錯改)

以上都還只是發生在工程端的問題, 如果各部門之間的語言沒有統一, 業務端和工程端的溝通不良會導致誤會, 以及衍生其他問題: 需求實作錯誤, 到了驗收階段才發現

可能有的人會想說是需求描述的不夠清楚, 但對於一個常態的業務流程, 我想是否只要清楚地描述一次就行, 不要每次都要將重複的內容再次羅列?

自己想到的解決方式是各部門開會協商, 決定一個最終的說法和定義, 起碼溝通時不會有歧義
不過這樣只是業務端和工程端的溝通沒有歧異, 在工程端實作的時候要怎樣保持大家有同樣的認知?

小結

忘了何時第一次看到 DDD, 並且對於 DDD 在做甚麼感到有興趣想要了解
我想可能是先看到 "活文檔" 這本書, 然後間接看到 DDD
我就這樣帶著這樣上面的疑問, 展開 DDD 的探索