Hands-On Modeler

人們總是把軟體開發比喻成製造業。通過這個比喻可以推斷出一個結論：經驗豐富的工程師做設計工作，而技能水平較低的勞動力負責組裝產品。這種做法使許多專案陷入困境，原因很簡單——在軟體開發中設計是無處不在的。開發團隊中的每個成員都有自己的職責，但是將分析、建模、設計和程式設計工作完全分離會對Model-Driven Design 產生不良影響。

作者經在一個專案中負責協調不同的應用程式開發團隊，幫助開發可以驅動程式設計的領域模型。但是管理層認為建模人員就應該只負責建模工作，編寫程式碼就是在浪費這種技能，於是他們不準作者編寫程式碼或者與程式設計師討論細節問題。

開始專案進展得還算順利。作者和領域專家以及各團隊的開發負責人共同工作，消化領域知識並提煉出了一個不錯的核心模型。但是該模型卻從來沒有派上用場，原因有兩個。

其一，將模型傳遞給開發人員的過程中，模型的一些意圖並沒有像他們說明。模型的整體效果受細節的影響很大，這些細節問題並不時總能在UML圖或者一般討論中遇到的。如果我能做好準備，直接與開發人員共同工作，提供一些參考程式碼和近距離的技術支援，那麼他們也許能夠理解模型中的抽象概念並據此進行開發。

第二個原因是模型與程式實現及技術互相影像，而我無法直接獲得這種反饋。例如，程式實現過程中發現模型的某部分在我們的技術平臺上的工作效率極低，但是經過幾個月的時間，我才一點一點獲得了關於這個問題的全部資訊。也許只需較少的改動就能解決這些問題，但是接個月過去了，改不改已經不重要了。因為開發人員已經自行編寫出了可以執行的軟體——完全脫離了模型的設計，在那些還在使用模型的地方，也僅僅是把他當做純粹的資料結構。開發人員不分好壞地把模型全盤否定，但是他們又有什麼辦法呢？他們再也不願意冒向人有待在象牙塔裡的架構師擺佈了。

與其他專案一樣，這個專案的初始環境傾向於不讓建模人員參與太多的程式實現。對於該專案所使用的大部分技術，作者有著大量的實踐經驗。在做建模工作之前，作者甚至曾經在同類項目中領導過一個小的開發團隊，所以作者對專案開發過程和程式設計環境分非常熟悉。但是如果不讓建模人員參與程式和實現，作者就是有這些經歷也無法有效的工作。

如果編寫程式碼的人員認為自己沒必要對模型負責，或者不知道如何讓模型為應用程式服務，那麼這個模型就和程式沒有任何關聯。如果開發人員沒有意識到改變程式碼就意味著改變模型，那麼這個模型就和程式沒有任何關聯。如果開發人員沒有意識到改變程式碼就意味著改變模型，那麼他們對程式的重構不但不會增強模型的作用，反而還會削弱模型的效果。同樣，如果建模人員不參與到程式實現的過程中，那麼程式實現的約束就沒有切身的感受，即使有，也會很快忘記。Model-Driven Design 的兩個基本要素（即使模型要支援有效地實現並抽象出關鍵的領域知識）已經逝去了一個，因此最終模型將變得不再使用。最有一點，如果專案組的分工阻斷了設計人員與開發人員之間的協作，是他們無法領悟Model-Dirven Design的奧妙，那麼經驗豐富的設計人員則不能將自己的知識和技術傳遞給開發人員。

因此：

任何才與建模的技術人員， 不關在專案中主要職責是什麼，都必須花時間瞭解程式碼。任何負責修改程式碼的人員則必須學會用程式碼來表達模型。每一個開發人員都必須不同程度的參與模型討論並且與領域專家保持聯絡。參與不同工作的人都必須有意識的Ubiquitous Language與接觸程式碼的人及時交換關於模型的想法。