io.github.dddplus.model

接口 IUnboundedDomainModel

所有超级接口:

IDomainModel

public interface IUnboundedDomainModel
extends IDomainModel

非限定上下文下的领域对象.

承载自然属性，回答了"它是什么"这个问题，不易变，与具体场景无关，与运营无关.

场景特有的(数据，规则，行为)，请分配到BoundedDomainModel，这样才能做到"场景与领域分离"，避免聚合根膨胀模糊.

否则，会将“个性”统统视为“共性”.

一个IUnboundedDomainModel可能衍生出多个BoundedDomainModel

例如：一个人(unbounded)，在家是父亲(bounded)，在公司是员工(bounded)，在课堂上是老师(bounded)，不同角色，如果这些上下文逻辑都写到人这个类，必然膨胀臃肿，成为上帝类

应该这样设计：分别为(父亲，员工，老师)建模，建立边界清晰，职责单一，认知负荷低的模型；此外，不同上下文的演化路径、变更频率是不同的，分开后互不干扰，降低上线风险

成为上帝类有什么问题？
• 难修改：低内聚，违反单一职责，关注点不分离，不隔离变化，任意场景的变化都会引起这个类的变化，本该最稳定的却成了最不稳定元素
• 难理解：一个类中包含太多信息，主次不分，整体与局部不分，信息过载，让维护者难以理解
• 难测试：会导致难维护的单测代码
• 破坏模型：信息组织未结构化，场景知识丢失，被隐藏了

领域和场景是不同的：领域是宏观层面，场景是微观层面.

在没有区分是否有界上下文对象前，聚合根里的行为其实可以理解为这样：

 

 class FooAggregateRoot implements ScenarioA, ScenarioB, ScenarioC, ScenarioD {
     void 与场景无关的通用方法() {}
     void scenarioAMethodXxx() {}
     void scenarioAMethodYyy() {}
 }
 
 

由于Java语言的限制，我们无法拆分class FooAggregateRoot，造成它膨胀臃肿.

而通过区分是否有界上下文对象，我们做到了class FooAggregateRoot的拆分：不同Scenario的接口方法被分配到不同的BoundedDomainModel，从而避免了类臃肿.