程式思維模型和領域思維模型

在工作站中，我實現過一個任務模組（為方便解說，以下作了部分簡化）。

任務分為三種：

• 簡單類型：由一系列單一的任務條目組成。對所有的任務條目按照從上到下的順序執行一次，任務便會結束。
• 群組類型：也是由一系列單一的任務條目組成。但可以迴圈執行多次。使用者可以設定迴圈的間隔時間。
• 複合類型：簡單類型和群組類型的任意組合。

任務條目可以包含多個任務項，這些任務項按照從左至右的順序執行。使用者可以設定任務項的間隔時間。

有一天，我們的應用工程師問我任務“組”有什麼用。

我簡單地回答說，它可以實現多個任務條目的迴圈執行。

應用工程師表示不理解。

我於是建立了一個工作群組，添加了任務條目A、B、C，繼續解釋說，一般的情況下，ABC執行一次就完了；但在某些情況下，需要對ABC進行反覆地執行，就是說，在C執行完畢後，又需要從頭再次執行一遍或多遍ABC。

應用工程師點了點頭，但還是有點疑惑，繼續問：那它在實際中到底能幹點什麼具體事務呢？

我立即蒙了。我只是一個小小的程式員，一個具體（設計）需求的實現者，我可以解釋實現的具體過程，但如何知道它能夠解決的具體的業務呢？當然，可以看看相關的文檔，找找原始的業務需求。可惜我們沒有文檔。

最後只好詢問頭頭這個精通業務的人。他解釋說，氣象部門會對每天的空氣品質進行測試；今天早上會在8點和9點測試一次，明天早上也會在8點和9點測試一次，每天早上都會會在8點和9點測試一次。在這種情況下，我們就可以使用工作群組。該工作群組只需要一個條目，這個條目擁有兩個任務項。這兩個任務項對應8點和9點的測試。因此，它們的間隔時間需要設定為1小時。顯而易見的是，任務條目應該每天執行一次。也就是說，9點的測試執行完畢的23小時後，繼續執行8點的測試，然後在一小時後，執行9點的測試；再等待23小時......如此反覆。對於氣象局的工作人員來說，只要在第一天的8點準時啟動工作群組就可以了。

頭頭描述了可以用工作群組解決的一個具體的業務，而應用工程師懂業務。

我描述了工作群組運行模式或者說叫規則。但我不懂業務，不知道這套規則可以解決哪些實際的問題。因此，應用工程師不會從我這兒獲得滿意的答案。

應用工程師傾向於實際的問題，傾向於現實的世界。我，一個程式開發人員，則傾向於問題解決方案的實現模型，傾向於電腦的世界。

這兩個世界對應開發中的兩個階段，它們中間還差著一個概要設計。也就是說，我和應用工程師處在兩個完全不同世界，因為語言不通而無法實現有效對話。