DDD架构学习
why
通过对DDD结构的了解,方便在服务化实践中更好的操作。
what
松散4层架构:
结构概图如下:
User Interface为用户界面层(或表示层),也可理解为对外接口层。负责向使用者显示信息和解释用户命令;
Application为应用层,定义软件要完成的任务,并且指挥领域对象来解决问题,并将domain的内容整合成具体业务需要的结果形式。应用层应该尽量简单,其不包含业务规则或者知识,而只为下一层中的领域对象协调任务,分配工作。
Domain为领域层(或模型层),是业务软件的核心,其负责表达业务概念、业务状态信息以及业务规则。。虽然保存业务状态的技术细节是由基础设施层实现的,但是反映业务情况的状态是由本层控制并且使用的。
Infrastructure层为基础实施层,向其他层提供通用的技术能力,为应用层传递消息,为领域层提供持久化机制。础设施层还能够通过架构框架来支持四个层次间的交互模式。
系统结构:
实践改造见后面的严格4层中的图。
领域层实现核心业务逻辑,负责表达领域模型业务概念、业务状态和业务规则。主要的服务形态有实体方法和领域服务。DDD 提倡富领域模型,尽量将业务逻辑归属到实体对象上,实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排,实现跨多个实体的复杂核心业务逻辑。
应用层的主要服务形态有:应用服务、事件发布和订阅服务,没有业务状态。为了实现微服务内聚合之间的解耦,聚合之间的服务调用和数据交互应通过应用服务来完成。原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联。
特点:
领域层的实体方法和领域服务可以直接暴露给应用层和用户接口层。松散分层架构的服务依赖关系,无需逐级封装,可以快速暴露给上层。
严4层架构:
每一层服务只能向紧邻的上一层提供服务。虽然实体、实体方法和领域服务都在领域层,但实体和实体方法只能暴露给领域服务,领域服务只能暴露给应用服务。
相对松散4层结构,Infrastructure只能由Domain层使用,并且Infrastructure依赖、继承Domian层的数据交互接口repository(即为domain层服务)。具体的依赖关系如下图:
依赖结构原因:业务领域模型低耦合,高内聚。防止数据依赖方的变化,特别是在商业化的项目中,客户的数据源千变万化。
系统中数据的层次关系:
数据持久化对象 PO(Persistent Object):与数据库结构一一映射,是数据持久化过程中的数据载体。
领域对象 DO(Domain Object):微服务运行时的实体,是核心业务的载体。
数据传输对象 DTO(Data Transfer Object):用于“前端与应用层”或者“微服务之间”的数据组装和传输,是应用之间数据传输的载体。
视图对象 VO(View Object):用于封装展示层指定页面或组件的数据。
实际使用中的折中:
应用层实现接口、负责领域服务的编排和组装外,还负责将中间结果数据直接转为接口的DTO
数据交互如下:
domain层中的一个聚合对应一个聚合代码目录,聚合之间在代码上完全隔离,聚合之间通过应用层协调。那么以后业务发展大了以后就可以方便拆分了。具体代码如下:
六变形架构:
六边形架构也称为端口与适配器,如下图:
六边形每条不同的边代表了不同类型的端口,端口要么处理输入,要么处理输出。对于每种外界类型,都有一个适配器与之对应,外界通过应用层API与内部进行交互;同时DDD战术设计的建模元素Repository的实现看作是持久化适配器,该适配器用于访问先前存储的聚合实例或者保存新的聚合实例。
六边型有很多演化,例如:
Jeffrey Palermo在2008年提出了洋葱架构,六边形架构是洋葱架构的一个超集。
Robert C. Martin在2012年提出了干净架构(Clean Architecture),这是六边形架构的一个变体。
Russ Miles在2013年提出了Life Preserver设计,这是一种基于六边形架构的设计。
参考学习文档:https://cloud.tencent.com/developer/article/1837097