MARTIN FOWLER 在 Accountability 分析模式中详细地列举了一个根据需求演变的分析过程
在一个企业架构图里, 最简单莫过于公司包含部门,部门包含人
这样的结构适合结构改变可能性小,而公司,部门和人三者的行为有很大区别时使用(类型是一种奢侈品)
反过来说,事实上大多数结构还是会有一定变动的,比如部门和人之间加入了组的概念,那么原来部门组合人
的聚合就完全推翻了,如果公司,部门,组和人的行为如果没有太大区别的话,把他们抽象为一个类型--PARTY
.用一个组合模式已经可以表达.
以上的解决方案是为解决一种行政性的架构而设定的,但如果来了些更复杂的需求,比如架构按地域来分,或者跨行政类型和地域类型来做架构,
比如上海的某个小组能管广州的某个部门,那么情况就复杂了,要每种架构都创建一个新的类型吗,估计结构图会相当复杂并且繁多,以后每新建
一个架构都需要开一个新的类型,这是设计者最避忌的"设计缺乏伸缩性",当前的组合结构不能解答这些这个问题.
That's why When Typey meet Objecty 当类型遇上实体 comes into play.
MARTIN FOWLER为了避免架构膨胀引发的类型膨胀，根据架构定义的稳定性创建了架构（ACCOUNTABLITY TYPE）类型（属元数据类型，关于元数
据类型请看我的另一随笔“领域建模 初级阶段(原创)” ），由ACCOUNTABLITY TYPE的一个实体来表示一种架构类型。好了，膨胀给压制了，
那么如何来替换原来的组合关系呢？我估计MARTIN是这样考虑的，一个单位（PARTY）和单位之间的关系已经变得具有多重性了，比方说a公司
和b部门可以因为行政的关系成为上下级,也可以因为地域的关系成为上下级.所以原来的一对多的上下级关系变成一个上级对一个下级的关连,
关联属于哪个架构由ACCOUNTABLITY TYPE的实体来表达.
