领域模型细化的两个注意点

最初的[[领域模型的定义与两种表示形式]]是”领域建模”活动产生的，到了细化架构设计阶段，还要进一步做”领域模型细化”——这一步之所以必要，是因为前期的领域模型并不面向实现：作为设计者要检查领域模型中是否已经区分了接口和具体类、是否还遗留有”关联类”这类没有任何编程语言能直接支持的抽象概念、是否为每个属性都定义了类型、类的方法或成员函数是不是都还没有定义。细化领域模型时，模型的调整和改变在所难免，有两点是架构师尤其需要注意的。第一，最初的”领域建模”并不区分”类”和”接口”，统统按”一般化的类”对待；到了”细化架构”环节，则必须明确区分”类”和”接口”，并进一步把领域模型设计到可以编程实现的程度——这是从”概念级抽象”到”实现级抽象”的一次关键跃迁，不能停留在领域建模阶段那种笼统的表达方式上。第二，细化架构环节经常需要根据实际情况，把前期的类”降格”成属性、或者把前期的属性”升格”成类。书中举了PM Suite自己的例子：第7章讨论过的PM Suite领域模型里，”前置任务”这类关系原本被建模成了独立的类（比如”结束-开始”关系单独成类），但到了逻辑架构设计做领域模型细化时，应该把这些关系调整成属性——具体做法是引入一个”任务关系”类，其中有一个task_relation属性，属性的类型TaskRelationContants是一个枚举，用END_BEGIN、BEGIN_BEGIN等4个常量代表原来分散建模出来的”4个子类”。这个具体例子直接呼应了第7章讨论过的[[可扩展性评审暴露的任务依赖关系模型缺陷]]——把关系类型从”每种关系一个类”重构成”一个属性+一个枚举”，正是解决那个案例里”接口必须随依赖类型增加而改变”这个可扩展性缺陷的具体实现路径。