領域驅動設計學習筆記（15）：領域專家缺貨
source link: http://teddy-chen-tw.blogspot.com/2021/04/15.html?showComment=1619533903935
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
領域驅動設計學習筆記（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，就可以變得很靈活。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK