DDD 中為人所忽略的『軟體工程』與『工程實踐』方法
圖片來源：https://zhuanlan.zhihu.com/p/32196548?from_voters_page=true 我們知道架構設計需要從業務角度出發，我也寫過許多類似的內容，像是：『從使用者需求、談架構設計』、『您的軟體架構夠敏捷嗎？』等等、這些都是從業務角度出發嗎？這可以說對，但也可以說不完全對。。。怎麼說呢？ 我們談論 軟體開發／架構設計 時，常聽到有人說，技術團隊與業務團隊溝通不良，導致技術團隊做白工！或者是技術團隊聽不懂業務團隊在說什麼？搞不清楚重點。而業務團隊也常常抱怨技術團隊沒辦法溝通，總是說著一堆技術專有（名詞／詞彙）導致無法溝通下去！ 很熟悉吧？相信這是大家常聽到許多人嘴巴在說的。 我們再回到我一開始講的，業務角度出發，這出發點是對的沒有錯， 但是我講的是我們開發軟體系統是要開發出符合客戶期望 + 能夠替客戶解決問題 + 符合客戶所想的，對！所以即便你與業務單位溝通融洽、沒有聽不懂的、雙方也沒有疑問，但是這不代表你做出來的系統就完全符合客戶所期望，還有，也不代表實作出來的系統是不是很容易地在這個客戶的『商業需求』上很容易地擴充 與 能夠進行最低成本的修改，對！不見得喔！XD 業務與技術單位溝通沒有隔閡，不代表技術完成品是妥當的！ 業務與技術單位溝通沒有隔閡，不代表技術完成品是妥當的！ 業務與技術單位溝通沒有隔閡，不代表技術完成品是妥當的！ 敏捷有一個非常重要的出發點就是，替客戶創造價值，並在反覆設計／反饋／ Retro 中修正方向以達成客戶期望，但是... 這個過程走得不扎實，光是技術債爾後就會把你壓死，也就是說： 能否達成客戶期望是一回事 ！達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 能否達成客戶期望是一回事 ！達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 能否達成客戶期望是一回事 ！達成客戶期望後的產出以後你 自己能不能維護 那又是另外一回事。 近年來我的文章 & 教學大部分圍繞在一個重點就是在需求內使用適當的技術下【產生】適當的軟體架構來解決 商業需求 ，產生的過程、如何產生？甚至如何讓你商業需求直接（對應／轉換）程式碼一直是我研究的重點，近幾年來開始盛行的 DDD 也是在降低業務團隊 (我這裡精確的是 USER，USER 不等同於業務團隊這是有差別的！) 開發團隊 的溝通成本，而降...