逻辑视图的一种推荐方法就是DDD,即领域驱动模型。它聚焦业务领域,以业务模型而非技术实现作为架构设计的驱动力,从而实现业务逻辑上的松耦合。
DDD战略设计
通过限界上下文进行系统划分。
将大型系统分解成若干易于理解的领域,领域由限界上下文来界定。领域,限界上下文围绕业务进行,与技术无关。限界上下文的首要划分原则是业务相关性。
同一限界上下文内,将采用统一语言,确保概念统一,而不同的限界上下文中,概念进行分离和映射。
以电商为例
真实世界由商店store和warehouse仓库,可以构成两个不同的限界上下文。store和warehouse都有product概念,但两者不同。在warehouse中product只关注物体的特征,如尺寸,重量等;而store中product则关注price和外观等。因此这是两个不同的概念。
如果强行跨界定上下文建立统一概念,会造成域间的数据耦合(如宽表),而通过将概念分离到不同的上下文中,通过明确的上下文映射建立关联,则解耦为接口关联。
DDD战术设计
限界上下文内部的领域模型
- 在领域内部,通过识别聚合,实体,值对象等元素,并建立领域模型
- 领域模型是对业务的高度抽象,利用抽象模型作为业务和系统实现的核心联系,领域模型封装和承载了全部的业务逻辑,并通过聚合的方式保持业务的高内聚聚,低耦合。
- 在领域中,不同的实体和值对象都可能有归属关系,通过寻找归属关系,可找到最终归属实体,即聚合根,并形成聚合
- 聚合根也是一种实体,是聚合的根节点
- 聚合根负责执行业务规则,有全局标识,而聚合根挂接的实体只有局部标识,在聚合内唯一
- 聚合边界外的对象只能引用聚合根,以及对聚合根操作,即聚合根承接了聚合对外接口
- 对聚合根的操作建模为命令和事件两种类别,通常命令实现为同步调用,直接返回,事件实现为无需返回的消息
- 领域模型是限界上下文中的细节建模,可承载逻辑模型(对象关系,接口关系)和数据模型(聚合中的对象和数据归属)