領域驅動設計學習筆記（15）：領域專家缺貨

April 27 17:12~17:48

▲David West提到在1968年代，銀行的開發人員就是領域專家

不少朋友問Teddy一個問題：「Event Storming工作坊的時候如果領域專家不願意參加，或是勉強參加但卻都在擺爛，被動等著開發人員去問他問題，這樣該怎麼辦？」

這是一個很常見的問題，因為許多公司，特別是大公司，雖然嘴上說導入敏捷好幾年了，但骨子裡還是傳統瀑布是開發方法，客戶（業務單位）與開發人員還是透過中間人所產生的文件來溝通。這個中間人可能是Scrum裡面的Product Owner（PO），或是傳統的專案經理或是系統分析師/商業分析師。客戶（業務單位）認為開發軟體是開發人員的事情，能講的他們都已經講完了，這些開發人員不要三不五時就跑來煩他們，趕快把東西生出來。

另一方面，客戶（業務單位）理論上雖然代表著領域專家的角色，但這並不表示他們有能力和開發人員一起析分商業流程，甚至有些商業邏輯的細節連他們也不十分清楚。再加上客戶（業務單位）的人日常工作量已經很多，自己的事都忙不過來，很難要求他們長時間配合開發團隊持續進行Event Storming並精煉領域知識以及共通語言。

***

所以，如果你的開發團隊有願意一起長時間配合的領域專家，恭喜你你的現況離理想狀況比較接近。如果沒有，也不要灰心喪志，日子還是要過下去。

領域專家「缺貨」怎麼辦？如果真的調不到「貨」，只好讓自己變成領域專家。

幾天前Teddy聽了David West的〈 The Past and Future of Domain-Driven Design〉演講，講者提到在1968年代，銀行的開發人員就是領域專家。在【搞笑談軟工臉書社群】上，有兩位朋友也分享了類似的經驗。

所以，萬一開發專案中真的沒有領域專案，而案子也還是要做下去，考慮訓練自己成為領域專家。這樣做一定會花費比較多的時間，走更多的冤枉路，但總是能緩慢往前移動，總比留在原地一動也不動來的好。

就算團隊中有領域專家，開發人員也不能完全信任領域專家，自己還是要動腦思考，畢竟要將問題領域（problem domain）轉化成解法領域（solution domain）的人，是開發人員，不是領域專家，開發團隊還是要多擔待一些。

***

友藏內心獨白：一個人或是一個團隊的End-To-End，就可以變得很靈活。