空間、運動（時間）以及程式設計師

目錄樹中出現的節點有很多種，有ResourceType、Field、Dic、DicItem、Function、Organization、AppSystem等，這些catalog節點記錄存在的意義是可以提供一套一致的方法去管理和使用它們。比如賬戶節點下的賬戶稽核狀態字典，這個字典裡列舉出來的值也可以在程式設計的時候去在程式裡寫死，或者寫個Enum型別列舉這些取值，但是那樣不靈活。它們都一致的出現在Catalog目錄樹上是為了統一管理，良好的管理，統一執行。

空間堆積原則，遵循構造定律，最大限度節省腦力

我們的系統中可能並沒有Person模型，系統內可以並不顯式的對應有Person“模型”，但是我們最好對應有Person“概念”，我們建立人的性別字典的時候我們最好先建立一個Person節點，然後在Person節點下建立Gender字典。我們建立一個Person節點，然後在Person節點下建立了Gender字典。我們使用這個字典的時候可以直接從頭腦中找到這個人類性別字典在目錄樹上的索引碼，我們可以直接透過“Person.Gender”去索引這個性別字典，因為建立這個字典的時候我們考慮了足夠多，這個字典不會隨著我們的系統的改變而改變。除非人會出現第三種性別這個人的性別字典才會改變，這個A系統我們透過“Person.Gender”索引人的性別字典，換做B系統我們一樣使用同樣的編碼。我們不編碼為Employee.Gender，不編碼為User.Gender，不編碼為Customer.Gender，我們編碼為Person.Gender，雖然我們的系統中並沒有Person模型，並沒有個Person Class。

程式設計師腦子裡不應該只有string、int、boolean等目錄節點
這群目錄樹可以幫助我們儘量避免C硬編碼，我們儘量透過那些Catalog目錄樹上記錄的資訊去實現我們的邏輯，我們寫程式碼的時候隨時應想著那個Catalog目錄樹上有什麼資訊，隨時想著藉助目錄樹上的資訊實現邏輯，那棵目錄樹上的內容不止可以被C程式碼訪問，也可以被嵌入的javascript和xacml等指令碼訪問。

我們程式設計師寫程式碼的時候可以寫“Person.Gender”這樣的字串，透過這個字串索引到性別字典，但是系統執行的時候在機器中是使用的Guid。只有與程式設計師打交到的時候才是可讀的字串，與終端使用者打交道的時候是可讀的漢字“男"。但是考慮到目錄樹的層級性，目錄樹上的節點的編碼都是有層級的，都是類似"Anycmd.Person.Gender.Nan"這樣的層級結構，編碼上記錄了層級。有時候這些層級結構會有用，比如組織結構的層級就是有用的，在資料庫中我們會使用like '1001%'來篩選一個組織結構的下級組織結構，這種情況又需要我們直接儲存這種有層級的組織結構編碼而不是它的Guid。而字典可以儲存Guid，因為字典沒有層級。

把握好結構和運動，不要人為製造一團亂麻的圖形
還有一個問題是這樣：Employee、User、Customer是否要繼承Person呢？Employee、User、Customer節點是否要作為Person節點的子節點出現在Person節點之下呢？
不需要。所有促使我們分析問題時往圖的方向一團亂麻的都是因為運動，因為運動需要圖，結構和運動這兩個維度交差在一起時容易讓我們一團亂麻。應對這個困難的辦法可能是：不要檢視在結構樹上“顯式”運動樹（執行時樹）。
Employee和User和Customer並非一定是人。計算機世界不是在完整模擬現實世界，計算機中的Person、User、Employee、Customer都不是完整的本神，它們都是分神，都是外部事物在計算機中的投影，計算機中的投影不具有本神完整的資訊，也不需要具有完整的資訊。Employee和User和Customer節點下也可以有Sex”欄位“，只不過是把這個欄位的值域繫結在Person節點下的Person.Gender字典上而已。

圖形是短暫的，樹形是常態的

靜態的結構樹投影在動態的運動樹上的影子已經不是樹形，動態的運動樹投影在靜態結構樹上的影子也不再是樹形。兩者的維度混合在一起時是圖形，是在樹的區域性製造的通路，通路中奔跑著的是攜帶著資訊的能量，能量之所以在通路中奔跑是因為通路兩端存在不等（差、場），攜帶資訊的能量移動到達目的後，控制器（我們程式設計師書寫的程式碼）在通路的某個地點又將通路斷掉，從而世界再次回到穩定的樹形。整個過程消耗了能量，所以只要能量源源不斷的輸入進去的話，我們的系統應該會一直持續下去。不僅消耗了電能，更重要的是消耗了程式設計師的能量。