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对象

参考
限界上下文[参考]( https://blog.csdn.net/maoyeqiu/article/details/109221146#:~:text=限界上下文：. 主要是语言层面上的限界划分，是实现DDD的关键。. 一个限界上下文并不一定只包含在一个子域中。. 限的意思就是划分、规定，界就是界限、或者一个边界，上下文就是业务的整个流程。. ,%E9%99%90%E7%95%8C%E4%B8%8A%E4%B8%8B%E6%96%87%E5%AE%9A%E4%B9%89%E4%BA%86%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B%E7%9A%84%E8%BE%B9%E7%95%8C%EF%BC%8C%E7%9B%AE%E7%9A%84%E6%98%AF%E6%B8%85%E7%90%86%E5%AD%90%E5%9F%9F%EF%BC%8C%E7%84%B6%E5%90%8E%E5%8C%BA%E5%88%86%E5%AD%90%E5%9F%9F%E5%93%AA%E4%BA%9B%E6%98%AF%E6%A0%B8%E5%BF%83%E5%9F%9F%E3%80%81%E6%94%AF%E6%92%91%E5%AD%90%E5%9F%9F%E5%92%8C%E9%80%9A%E7%94%A8%E5%AD%90%E5%9F%9F.%20%E9%99%90%E7%95%8C%E4%B8%8A%E4%B8%8B%E6%96%87%E6%98%AF%E4%B8%80%E4%B8%AA%E6%98%BE%E5%BC%8F%E7%9A%84%E8%BE%B9%E7%95%8C%EF%BC%8C%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B%E4%BE%BF%E5%AD%98%E5%9C%A8%E4%BA%8E%E8%BF%99%E4%B8%AA%E8%BE%B9%E7%95%8C%E4%B9%8B%E5%86%85%E3%80%82.%20%E5%88%9B%E5%BB%BA%E8%BE%B9%E7%95%8C%E7%9A%84%E5%8E%9F%E5%9B%A0%E5%9C%A8%E4%BA%8E%EF%BC%8C%E6%AF%8F%E4%B8%80%E4%B8%AA%E6%A8%A1%E5%9E%8B%E6%A6%82%E5%BF%B5%EF%BC%8C%E5%8C%85%E6%8B%AC%E5%AE%83%E7%9A%84%E5%B1%9E%E6%80%A7%E5%92%8C%E6%93%8D%E4%BD%9C%EF%BC%8C%E5%9C%A8%E8%BE%B9%E7%95%8C%E4%B9%8B%E5%86%85%E9%83%BD%E5%85%B7%E6%9C%89%E7%89%B9%E6%AE%8A%E7%9A%84%E5%90%AB%E4%B9%89%E3%80%82.%20%E8%80%8C%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B%E9%9C%80%E8%A6%81%E5%87%86%E7%A1%AE%E7%9A%84%E5%8F%8D%E6%98%A0%E9%80%9A%E7%94%A8%E8%AF%AD%E8%A8%80%E3%80%82.%20%E5%9C%A8%E5%BE%88%E5%A4%9A%E6%83%85%E5%86%B5%E4%B8%8B%EF%BC%8C%E4%B8%8D%E5%90%8C%E6%A8%A1%E5%9E%8B%E4%B8%AD%E5%AD%98%E5%9C%A8%E5%90%8D%E5%AD%97%E7%9B%B8%E5%90%8C%E6%88%96%E7%9B%B8%E8%BF%91%E7%9A%84%E5%AF%B9%E8%B1%A1%EF%BC%8C%E4%BD%86%E6%98%AF%E4%BB%96%E4%BB%AC%E7%9A%84%E6%84%8F%E6%80%9D%E5%8D%B4%E4%B8%8D%E5%90%8C%E3%80%82.)

  限界上下文定义了领域模型的边界，上下文就是业务的整个流程
  限界上下文是一个显式的边界，领域模型便存在于这个边界之内
  限界上下文主要用来封装通用语言和领域对象，但同时它包含了那些为领域模型提供交互手段和辅助功能的内容

  Infrastructure: 基础实施层，向其他层提供通用的技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现)
  Domain: 系统核心层、领域层，主要负责表达业务概念,业务状态信息和业务规则；是整个系统的核心层,几乎全部的业务逻辑会在该层实现
  Application: 应用层，应用层是很薄的一层,应用层定义了软件要完成的任务,要尽量简单
  Interfaces: 展现层，负责向用户显示信息和解释用户命令，请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)

案例一

参考
官方案例
Application：例如领域层中的MerchantService是一个service接口，有具体的业务；之后在MerchantDomain中实现

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实现类、封装对象、持久层

案例二

参考

案例三

案例四

案例五

案例五

补充

posted @ 2022-06-22 22:45 DogLeftover 阅读(86) 评论(0) 收藏举报

刷新页面返回顶部