應用定義與執行環境

在實踐中

要看清這條線，最快的辦法是看它不存在的時候會怎樣。在一個「生成出來」的應用裡，定義和執行環境是同一個產物：生成器把一份說明變成控制器、表單和遷移腳本，從那一刻起，那份說明就成了歷史文件。沒有任何東西會再讀它。改生成的程式碼，說明就錯了；改說明，程式碼毫無反應。而在保留這條線的系統裡，宣告始終是活的源頭——引擎在每次請求時都去查它，於是兩者之間沒有可以互相走散的縫隙，也沒有一次需要有人記得去做的「重新生成」。

大家真正關心的後果是鎖定，而它有常被混為一談的兩半。一個開放的定義格式，配上唯一一個能執行它的私有引擎，並不叫可移植——不管檔案多好讀：你可以把宣告帶到別處，那裡沒有任何東西跑得起來。一個開放的引擎，配上沒有文件的內部格式，同樣不叫可移植——你可以自己託管它，直到你想讀懂它託管的到底是什麼為止。可移植需要兩半同時成立：一份不用執行就能讀、能 diff 的定義，加上至少一個你自己能運維的執行環境。

反對這條分界的最強論證值得原樣擺出來：一個同時擁有兩半的一體化系統，工程上可以做得更好。它可以讓格式和引擎一起演進，做出那些必須同時改兩邊才能實現的能力，也避免了一個穩定宣告格式所帶來的相容負擔。這個論證對「單一產品、單一廠商」是成立的。它失效的時刻，是當有好幾方開始依賴同一份宣告——應用本身、呼叫它的 Agent、事後覆盤的審計方，以及那些永遠不會互相協調發版節奏的第三方工具。

實際的檢驗是兩個問題，而且一下午就能答完。你能不能不執行就讀完整個應用——開啟一個檔案，看清一個物件是什麼、誰可以編輯它、哪一步需要審批？以及，另一個獨立實現的執行環境，能不能執行同樣這批檔案？第一個答「能」、第二個答「不能」是最常見的情況，值得誠實地承認，而不是算作通過。