最近公司安排了實現一個需求。
要給不同層級的部門，分配個“審批人”的角色。有的部門分配，有的部門不分配。在實現審批功能時，讓單據所在部門設置的審批人來審批。
如果這個部門沒有審批人，就往上追這個部門的父部門，父部門有審批人，就調用這個審批人，父部門沒有，就再往上追，到公司這一層肯定會有一個審批人。
但是，所有的部門按業務方向分爲前臺、中臺、後臺三種。還可能會爲這三個方向分別安排一個審批人。
如果查找審批人的過程中，查到了一級部門（公司層級緊下面一層）還沒有審批人，還要查找業務方向的審批人。如果業務方向也沒有審批人，纔會去找公司的審批人。
但是業務方向只和一級部門有關，如果一級部門是前臺，那這個一級部門下的所有子部門都是前臺。
現有的數據模型如下：
(圖1)
根據現有規則，對審批人查找流程總結如下：
1，先找單據所在部門（下稱部門A，這裏假設它不是一級部門）的審批人，若找到，跳出查找流程；若找不到，則查找部門A的上級部門。
2，找到A的上級部門B，判斷B是否設置了審批人，若找到，跳出查找流程；若找不到，判斷B部門是否是一級部門。
3，如果B部門不是一級部門，跳到第2部，繼續向上找；如果B部門是一級部門，判斷B部門是哪個業務方向。
4，如果業務方向上有審批人，跳出查找流程；如果沒有，去查找公司的審批人，公司一定有審批人，如果沒有，拋錯。
聽運營人員講完現有模型，隱隱感到不安。按照現有模型去做的話，不僅有很多的邏輯判斷，而且會有高耦合的硬編碼。如，對一級部門的判斷，對業務方向的判斷等。
對於領域驅動設計人員來說，如果是做新東西，最重要的工作就是做出一個符合業務本質的領域模型；那如果已經有了模型，就應該分析這個模型是否抓住了本質。
如果模型複雜度比較高，而業務邏輯並沒有那麼複雜的話，通常就是模型不合理，導致的邏輯複雜。
那我們來判斷業務方向到底是不是部門的屬性。在數據表裏，由於是關係型數據庫，所有的部門都會有一個業務方向字段。
比如在部門樹裏，一個部門C，向上追到一級部門是D，那麼D部門是什麼業務方向，C就是什麼業務方向。
也就是說，業務方向屬性，只對一級部門有效。對於一級部門的所有下級部門是無效的。那其實業務方向就不是一個部門的屬性。
它其實應該是一個隱藏的級別，見下圖：
(圖2)
由於圖2所表示的部門樹並非完全真實的部門級層關係，但數據可以完全來源於真實的部門樹。所以我給它起了個名字叫“影子部門樹”。
在真實部門樹發生變動時，重新生成影子部門樹，然後把審批人，掛在影子部門樹上，就可以把邏輯簡化成如下：
1，先找單據所在部門（下稱部門A，這裏假設它不是一級部門）的審批人，若找到，跳出查找流程；若找不到，則查找部門A的上級部門。
2，找到A的上級部門B，循環執行查找審批人的操作。
這樣設計的話，避免了很多無用的概念和邏輯。 如果在最初設計數據模型時就能抓到模型的這種本質的話，那節省的人力物力不是隻使用一些設計原則和快速框架能比擬的。
畢竟這是業務層級的設計。
這也體現了領域驅動設計的重要性。架構人員應該培養自己對模型本質的敏銳的直覺。