canonical

    我在各種場合一直都在強調結構問題是獨立的，在程序語言之外存在著獨立的，可研究的，富有成效的結構問題。http://canonical.javaeye.com/blog/147424 在這個方向上更進一步，我們注意到所有的代碼并不是天然出現的，而是由人所編制的，因此代碼世界內部并不構成封閉的，自足的某個世界。代碼中的結構問題并不是由代碼本身完全解決的，即在代碼之外仍然存在著技術上可研究的結構問題。
    我們在編制代碼的同時也在編制著大量的說明文檔。這些文檔描述了代碼片斷之間的相互關系，描述了代碼未來的擴展方向，描述了代碼之間的可能的交互方式，同時也描述了針對現有代碼實現的很多具體約束。例如我們在文檔中約定某個量要在10和20之間，但在代碼中卻不一定顯式進行了判斷。針對代碼結構的很多具體約束條件和相關性描述可能只在文檔中體現，只在程序員的頭腦中存在，而并不一定忠實的在代碼結構中得到表達。
    我在設計領域基本持有一種物理實在論，即某種技術相關的約束應該在技術世界中通過技術手段得到表達。只是這里的技術手段卻不一定指在應用中加上特定的代碼實現，雖然我們在代碼實現中更直接的表達設計要求無疑是需要提倡的。為了在程序中有效的維護結構相關性，我們并不一定需要抽象出所有可能重用的代碼，并不一定需要確保某一概念在程序中只有精確的唯一的表達。程序中難以直接精確表達的弱關聯，仍然可以通過開發/設計工具等技術手段得到有效的維護。我們需要保證的是代碼世界中知識的自恰性，而自恰性并不等于唯一性。http://canonical.javaeye.com/blog/33788
    在Witrix中我們采用一種物理模型驅動的開發方式，http://canonical.javaeye.com/blog/29412 由pdm模型出發，自動生成hibernate的hbm文件，java實體類，元數據meta文件，前臺Action注冊文件等。生成的配置文件通過syncWithModel標記與模型保持著穩定的關聯。所有配置文件都支持手工修改，開發工具識別syncWithModel標記，當pdm模型發生變化的時候，工具自動將變化信息同步到各個配置文件中。注意到這里并不是采用一個統一的元數據模型的方式，各個配置文件所表達的信息在一定程度上是重復的，也可能是不一致的。例如后臺數據庫允許保存100個字節，但是前臺meta中我們可能配置只允許錄入20個字節。根據不同應用場景的需要，我們可以在各個層面對每個配置文件進行獨立的調節. 當然,在一般情況下并不存在這種需要。整個開發過程中，信息表達的自恰性并不是在應用程序代碼中得到定義的,而是因為開發工具的存在而在技術上得到保證的。放松模型之間的唯一匹配要求，我們可以得到更加豐富，更加靈活的軟件結構。實際上我認為RoR(RubyOnRails)采用直接映射的ActiveRecord的方式雖然有效保證了系統變動中知識的一致性，但是如果不允許在各個層面上都能夠自然的定義某種偏離，它在復雜應用中的價值就要打上大大的折扣。