ddd:入门
前言
-
充血模型:在实体类中除了属性、getter、setter方法,还有一些业务方法
-
贫血模型:在实体类中只有属性和getter、setter方法,不能体现实体类在当前系统中的作用
-
仓库与工厂:将持久层所需的实体对象拆分出来,在持久层的接口方法中我们通常需要传入
参数
返回返回值
等;而这些参数和返回值我们可以新建一个类作为工厂,在工厂中构建持久层需要的对象 -
防腐层:通常我们会在业务层处理我们的业务逻辑,例如使用到rabbitmq发送消息,可以将发送消息的方法提取到一个类中,将这个类与业务层完全隔离开,业务类要处理这个业务逻辑时只需调用这个业务类即可;同时若以后想使用其他消息中间件时,同样只需新建一个类作为隔离层,实现同样的功能供业务类调用即可
-
最后我们发现service层中处理业务的方法都拆分了出去,只剩下了最简洁的业务逻辑
-
拆分后的优点:service层业务更加清晰;每个功能点都是隔离的,更方便单元测试;更易于开发,代码复用性强;框架也更容易更新迭代
VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来;例如在控制层返回`集合对象`给前端,这个封装的对象就是vo
DTO(Data Transfer Object):数据传输对象,例如数据库的某张表中有100个字段,我们某次操作只用到10个字段,使用dto来封装
DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体
PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系;例如要操作某张表,此次操作的字段用po封装
BO:business object业务对象,封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作
1. PO是一条交易记录,BO是一个人全部的交易记录集合对象
2. 主要作用是把业务逻辑封装为一个对象,这个对象可以包括一个或多个其它的对象
比如一个简历,有教育经历、工作经历、社会关系等等;我们可以把教育经历对应一个PO,工作经历对应一个PO,社会关系对应一个PO;
建立一个对应简历的BO对象处理简历,每个BO包含这些PO;这样处理业务逻辑时,我们就可以针对BO去处理
POJO:plain ordinary java object 简单无规则java对象
限界上下文定义了领域模型的边界,上下文就是业务的整个流程
限界上下文是一个显式的边界,领域模型便存在于这个边界之内
限界上下文主要用来封装通用语言和领域对象,但同时它包含了那些为领域模型提供交互手段和辅助功能的内容
Infrastructure: 基础实施层,向其他层提供通用的技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现)
Domain: 系统核心层、领域层,主要负责表达业务概念,业务状态信息和业务规则;是整个系统的核心层,几乎全部的业务逻辑会在该层实现
Application: 应用层,应用层是很薄的一层,应用层定义了软件要完成的任务,要尽量简单
Interfaces: 展现层,负责向用户显示信息和解释用户命令,请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)
案例一
public interface MerchantService {
/**
* 获取商户信息(获取聚合根)
*
* @param merchantId 商户Id
*/
RespBody<Merchant> getMerchant(Long merchantId);
/**
* 检查商户名称是否合法
*
* @param merchantName 商户名称
* @param exclude 需要判断排除掉的商户Id 为空则无需排除(例如新增时无需排除,更新时排除自身)
* @return 是否合法
*/
boolean checkMerchantName(String merchantName, Long... exclude);
/**
* 商户 入驻(即商户在平台注册)
*/
RespBody<Void> merchantComeIn(MerchantComeInDTO dto);
/**
* 商户 新增门店(商户可以新增一家或多家门店)
*/
RespBody<Void> addStore(AddStoreDTO dto);
}
-
个人理解:Infrastructure层用于存放公共类和全局配置、工具类等
-
Interfaces层则用于编写接口
-
Domain:实体类、service实现类、封装对象、持久层