最近公司安排了实现一个需求。
要给不同层级的部门，分配个“审批人”的角色。有的部门分配，有的部门不分配。在实现审批功能时，让单据所在部门设置的审批人来审批。
如果这个部门没有审批人，就往上追这个部门的父部门，父部门有审批人，就调用这个审批人，父部门没有，就再往上追，到公司这一层肯定会有一个审批人。
但是，所有的部门按业务方向分为前台、中台、后台三种。还可能会为这三个方向分别安排一个审批人。
如果查找审批人的过程中，查到了一级部门（公司层级紧下面一层）还没有审批人，还要查找业务方向的审批人。如果业务方向也没有审批人，才会去找公司的审批人。
但是业务方向只和一级部门有关，如果一级部门是前台，那这个一级部门下的所有子部门都是前台。
现有的数据模型如下：
(图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，循环执行查找审批人的操作。
这样设计的话，避免了很多无用的概念和逻辑。 如果在最初设计数据模型时就能抓到模型的这种本质的话，那节省的人力物力不是只使用一些设计原则和快速框架能比拟的。
毕竟这是业务层级的设计。
这也体现了领域驱动设计的重要性。架构人员应该培养自己对模型本质的敏锐的直觉。