DDD领域驱动-经典四层架构设计及应用详解_ddd领域模型设计

发福利了，具体请前往官网！！！

DDD分层与传统三层区别

根据DDD领域驱动设计原则，对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在DDD分层结构中既有联系又有区别， 个人认为主要有如下异同：

• 在架构设计上，在DDD分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层 其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。

;

• 在建模方式上，DDD分层的建模思维方式有别于传统三层 传统三层通常是以数据库为起点进行数据库分析设计，而DDD则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。 故在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达。
• 在职责划分上，基础设施层涵盖了2方面内容
  • 持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现
  • 通用技术支持，一些公共通用技术支持也放到基础设施层去实现。

DDD分层详解

四层架构图

  在该架构中，上层模块可以调用下层模块，反之不行。即

• Interface ——> application | domain | infrastructure
• application ——>domain | infrastructure
• domain ——>infrastructure

分层作用

领域对象

根据战术设计，关注的领域对象主要包括有

各层数据转换

• POJO（plain ordinary java object） ：简单java对象，个人感觉POJO是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。一个POJO持久化以后就是PO，直接用它传递、传递过程中就是DTO，直接用来对应表示层就是VO。（POJO、PO、DTO、VO都是处理流程中的名字，不是PO对应一个POJO，DTO对应一个POJO，VO对应一个POJO在有些情况下PO、DTO、VO是指同一个POJO）
• VO（View Object）：视图对象，主要对应界面显示的数据对象。它的作用是把某个指定页面（或组件）的所有数据封装起来。如果是一个DTO对应一个VO，则DTO等价于VO;但是如果一个DTO对应多个VO，则展示层需要把VO转换为服务层对应方法所要求的DTO，传送给服务层，从而达到服务层与展示层解耦的效果。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。
• BO（business object）：业务对象，主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。比如一个简历，有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO。这样处理业务逻辑时，我们就可以针对BO去处理。
• DTO（Data Transfer Object）：数据传输对象，主要用于远程调用等需要大量传输对象的地方。比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。在这里，我泛指用于展示层与服务层之间的数据传输对象。
• DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。它用来接收数据库对应的实体，是一种抽象化的数据状态，介于数据库与业务逻辑之间。一般在业务逻辑层（Service）对数据库（SQL） 进行访问时，用于接收数据。xxxDO，xxx即为数据表名。另外，DO与Entity的不同点就是DO是与数据库存在着某种映射关系的Entity，总的来说DO是Entity的一种。
• PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。最形象的理解就是一个PO就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。

DDD编码实践

代码结构描述

eg.后端Java代码工程为例， 表现层在此代码结构中表现为api层，对外暴露接口的最上层

├─com.company.microservice
│    │ 
│    ├─apis   API接口层
│    │    ├─model     视图模型,数据模型定义 vo/dto（大多数情況是一样的）
│    │    ├─assembler    装配器，实现模型转换eg. apiModel<=> domainModel
│    │    └─controller   控制器，对外提供（Restful）接口
│    │ 
│    ├─application   应用层
│    │    ├─service  应用服务，非核心服务
│    │    ├─task     任务定义，协调领域模型 
│    │    └─***      others
│    │ 
│    ├─domain   领域层
│    │    ├─common       公共代码抽取，限于领域层有效 
│    │    ├─events       领域事件
│    │    ├─model        领域模型 
│    │    │    ├─dict    领域划分的模块，可理解为子域划分
│    │    │    │    ├─DictVo.java       领域值对象
│    │    │    │    ├─DictEntity.java   领域实体，充血的领域模型，如本身的CRUD操作在此处
│    │    │    │    ├─DictAgg.java      领域聚合，通常表现为实体的聚合，需要有聚合根
│    │    │    │    └─DictService.java  领域服务，不能归与上述模型，如分页条件查询等可写在此处
│    │    │    ├─xxx
│    │    │    │    ├─xxxEntity.java         
│    │    │    │    ├─bbbAgg.java     
│    │    │    │    └─cccAgg.java        
│    │    ├─service      领域服务类，一些不能归属某个具体领域模型的行为
│    │    └─factory      工厂类，负责复杂领域对象创建，封装细节 
│    │ 
│    ├─infrastructure  基础设施层
│    │    ├─persistent   持久化机制
│    │    │    ├─po           持久化对象 
│    │    │    └─repository   仓储类，持久化接口&实现，可与ORM映射框架结合
│    │    ├─general      通用技术支持，向其他层输出通用服务
│    │    │    ├─config       配置类
│    │    │    ├─toolkit      工具类  
│    │    │    └─common       基础公共模块等
│    │ 
│    └─resources  
│        ├─statics  静态资源
│        ├─template 系统页面 
│        └─application.yml   全局配置文件

其中在上述目录结构中，Domain层中为对module进行划分，实际上默认该层只有一个模块，根据微服务划分可以进行增加模块来规范代码结构。

领域模型注入仓储类的问题

区别于传统的分层后，在domain中更多关注业务逻辑，考虑到要与spring框架集成，需要注意一个领域模型中注入仓储类的问题

在传统分层中，controller，service，repo均注册为spring管理的bean， 但是在domain层中，service一部分的业务逻辑划分到了具体的领域对象中去实现了，显然这些对象却不能注册为单例bean， 因此在此处不能沿用与原来分层结构中service层中通过@Autowired or @Resource等注入仓储接口，

关于这个问题，此处建议使用ApplicationContext实现

即通过一个工具类 ApplicationContextUtils 实现 ApplicationContextAware获取bean的方法，即 getBean()方法， 然后我们就可以在我们的领域模型中直接应用该工具类来获取Spring托管的singleton对象，即 xxxRepo=ApplicationContextUtils.getBean(“xxxRepository”)

@Component
public class ApplicationContextUtils implements ApplicationContextAware {
 
    public static ApplicationContext appctx;
 
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        ApplicationContextUtil.appctx=applicationContext;
    } 
 
    /**
     * @return ApplicationContext
     */
    public static ApplicationContext getApplicationContext() {
        return appctx;
    }
 
    /**
     * 获取对象
     *
     * @param name spring配置文件中配置的bean名或注解的名称
     * @return 一个以所给名字注册的bean的实例
     * @throws BeansException 抛出spring异常
     */ 
    public static <T> T getBean(String name) throws BeansException {
        return (T) appctx.getBean(name);
    }
 
    /**
     * 获取类型为requiredType的对象
     *
     * @param clazz 需要获取的bean的类型
     * @return 该类型的一个在ioc容器中的bean
     * @throws BeansException 抛出spring异常
     */
    public static <T> T getBean(Class<T> clazz) throws BeansException {
        return appctx.getBean(clazz);
    }
 
    /**
     * 如果ioc容器中包含一个与所给名称匹配的bean定义，则返回true否则返回false
     *
     * @param name ioc容器中注册的bean名称
     * @return 存在返回true否则返回false
     */
    public static boolean containsBean(String name) {
        return appctx.containsBean(name);
    }
}

考虑到代码结构简洁性，还可以封装一层仓储工厂，只用来获取相应的仓储Bean 。

/**
 * 简化版的仓储工厂--用来统一获取仓储的实现Bean
 *
 * @author jockeys
 * @date 2020/9/12
 */
public class RepoFactory {
 
  /**
   * 根据仓储接口类型获取对应实现且默认取值第一个
   *
   * @param tClass 具体目标类型
   * @param <T>    仓储接口类型
   * @return 如果不是指定实现，默认获得第一个实现Bean
   */
  public static <T> T get(Class<? extends T> tClass) {
 
    Map<String, ? extends T> map = ApplicationUtils.getApplicationContext().getBeansOfType(tClass);
    Collection<? extends T> collection = map.values();
    if (collection.isEmpty()) {
      throw new PersistException("未找到仓储接口或其指定的实现:" + tClass.getSimpleName() );
    }
    return collection.stream().findFirst().get();
  }
}

然后在领域模型中就可以直接调用该工厂方法来获取仓储接口的实现， 比如DictRepo为定义的仓储接口，DictDao为该接口的准实现类

//直接指定实现
DictRepo repo= RepoFactory.get(DictDao.class);
//不指定实现取Spring容器中默认注册第1位的Bean
DictRepo repo= RepoFactory.get(DictRepo.class);

一些个人思考…

上述经典四层架构，笔者更愿意理解为DDD在编码实现阶段的一个体现或应用。

补充一点：DDD除了在编码实践阶段，还体现在需求分析、设计阶段等过程，DDD推荐不割裂系统的需求和设计，我们这里可以合并称作系统建模过程

当然除了这个经典四层架构模型，DDD还有五层架构、六边形架构等，所以这里抛出一个问题，

项目按上述经典四层架构进行搭建，可以说是DDD架构实践么？

关于这个问题，笔者想引入一对哲学概念，哲学有言形式与内容，现象与本质等辩证关系（当然与本文可能也没啥太大关系啦）；从这两个角度来阐述本人的观点：

• 形式与内容：经典四层架构是一个DDD实现的形式，相当于给我们提供了一个框框来让我们自己去实现；在这个框框里面我们怎么实现是自由发挥的，但也是有约束的，这个约束体现在DDD对每一层的作用的约定，如每个层约定做了什么功能，充当什么角色等。尤其是对Domain层的约定，才是最重要的。那么我们按照哲学辩证的套话来说，形式上满足了DDD架构，但这应该是片面的，具体还要看内容，即具体实现是怎样的。
• 现象与本质：接着上述观点，如果要看实现，就要具体分析一下现象与本质嘞。上面笔者也有提到，DDD除了四层经典架构，还有五层架构（包括其演化的多层架构）、六边形架构等也都是DDD提供的架构模型（形式），那这些都可以理解DDD架构模式的外显形式，那么又有哪些共性呢？可自行查询，本文直接给结论，即它们都有Domain层，Domain层，Domain层（重要的事情说三遍~~，该结论DDD作者译著有写到…），所以不管架构模式怎么演化，Domain是核心不能变。 那么如上分析，我们在回到这个问题，我们是不是可以给出一个这样的答案： 形式上符合DDD架构，具体是不是DDD的架构实践，本质上还要看
  • （1）项目是否包括有Domain层；
  • （2）Domain层是否满足DDD战术篇的要求（或者可暂时简单理解为充血模型吧）

题外话：Spring与DDD

• Spring框架中，Spring为我们提供了@Service @Repository 等注解，为我们分离行为和行为（注册为Bean）和属性（数据模型），同时通过@Autowired在合适地方进行注入行为，因为行为被注册为Spring容器中的Bean后，减少了频繁创建行为的开销，只有属性的数据模型作为数据的载体来传递数据。提供很大的便捷性。但也阻碍了我们应用DDD编码实践， Spring框架主张分离，DDD思想主张合并，我们在Spring框架中使用DDD则需要在其基础上进行一些权衡取舍，即 如何将注册为Bean的行为穿插到原有的贫血模型中来构建充血模型是我们要解决的问题
• 关于这个问题，笔者使用了Spring框架提供的获取容器内已经注册的Bean接口，直接调用接口，在有属性的领域模型中来获取行为；主要还是体现融入领域模型中的部分Service获取仓储接口来实现持久化过程。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/404921