DDD之架构重构

码农~明哥

于 2024-10-28 17:47:28 发布

阅读量1.3k

点赞数 11

CC 4.0 BY-SA版权

分类专栏： DDD领域驱动文章标签：架构重构

本文链接：https://blog.csdn.net/CSDN_LiMingfly/article/details/143308223

DDD领域驱动专栏收录该内容

5 篇文章

订阅专栏

前言
MVC 旧工程腐化严重，迭代成本太高。DDD 新工程全部重构，步子扯的太大。这是现阶段在工程体系化治理中，我们所面临的最大问题：既想运用 DDD 的思想循序渐进重构现有工程，又想不破坏原有的工程体系结构以保持新需求的承接效率。
众所周知，MVC 分层结构是一种贫血模型设计，它将”状态“和”行为“分离到不同的包结构中进行开发使用。domain 里写 po、vo、enum 对象，service 里写功能逻辑实现。也正因为 MVC 结构没有太多的约束，让前期的交付速度非常快。但随着系统工程的长期迭代，贫血对象开始被众多 serivice 交叉使用，而 service 服务也是相互调用。这样缺少一个上下文关系的开发方式，让长期迭代的 MVC 工程逐步腐化到严重腐化。
MVC 工程的腐化根本，就在于对象、服务、组件的交叉混乱使用。时间越长，腐化的越严重。
在这里插入图片描述
在 MVC 的分层结构就像家里所有人的衣服放一个大衣柜、所有人的裤子放一个大库柜。衣服裤子(对象)，很少的时候很节省空间，因为你的裤子别人可能也拿去穿，复用一下开发速度很快。但时间一长，就越来越乱了。🤨 一条裤子被加肥加大，所有人都穿。
而 DDD 架构的模型分层，则是以人为视角，一个人就是一个领域，一个领域内包括他所需的衣服、裤子、袜子、鞋子。虽然刚开始有点浪费空间，但随着软件的长周期发展，后续的维护成本就会降低。
架构分层(DDD)
在 DDD 架构分层中，domain 模块最重要的，也是最大的那个。所有的其他模块都要围着它转。所有 domain 下的各个领域模块，都包含着一组完整的：model - 模型对象、service - 服务处理，以及在有需要操作数据库时，再引入对应的 IRepository - 仓储服务。这个 domain 的实现，就像是实现了一个炸药包，炸药包的火药、引线、包布等都是一个个物料被封装到一起使用。
在这里插入图片描述
A:应用封装 - app：这是应用启动和配置的一层，如一些 aop 切面或者 config 配置，以及打包镜像都是在这一层处理。你可以把它理解为专门为了启动服务而存在的。
B:接口定义 - api：因为微服务中引用的 RPC 需要对外提供接口的描述信息，也就是调用方在使用的时候，需要引入 Jar 包，让调用方好能依赖接口的定义做代理。
C:领域封装 - trigger：触发器层，一般也被叫做 adapter 适配器层。用于提供接口实现、消息接收、任务执行等。所以对于这样的操作，这里把它叫做触发器层。
D:领域编排【可选】 - case：领域编排层，一般对于较大且复杂的的项目，为了更好的防腐和提供通用的服务，一般会添加 case/application 层，用于对 domain 领域的逻辑进行封装组合处理。但对于一些小项目来说，完全可以去掉这一层。少量一层对象转换，代码的维护成本会降低很多。
领域封装 - domain：领域模型服务，是一个非常重要的模块。无论怎么做DDD的分层架构，domain 都是肯定存在的。在一层中会有一个个细分的领域服务，在每个服务包中会有【模型、仓库、服务】这样3部分。
E:仓储服务 - infrastructure：基础层依赖于 domain 领域层，因为在 domain 层定义了仓储接口需要在基础层实现。这是依赖倒置的一种设计方式。所有的仓储、接口、事件消息，都可以通过依赖倒置的方式进行调用。
F:外部接口 - gateway：对于外部接口的调用，也可以从基础设施层分离一个专门的 gateway 网关层，来封装外部 RPC/HTTP 等类型接口的调用。
类型定义 - types：通用类型定义层，在我们的系统开发中，会有很多类型的定义，包括：基本的 G:Response、Constants 和枚举。它会被其他的层进行引用使用。
从 MVC 到 DDD只是换了套别墅
在这里插入图片描述
你仍是把原有的烂代码平移到新的分层架构中，就相当于把老房子里的破旧家具衣物鞋帽搬过来而已。所以依照于软件设计的原则：分治、抽象和知识，但知识是设计原则和设计模式的运用。所以要想把代码写好，就一定是要把DDD + 设计模式，才能真的把代码写好
代码现状
一个接口一个实现，一个实现代码一片。一片一片，又一片，代码行数，两三千。
在这里插入图片描述
大部分我们在 MVC 工程分层结构下，参与开发的代码，基本都是定义一个接口，就写一片功能实现。功能实现中，如果看到有现成的接口，直接拿来复用。所有的实现并不会基于接口、抽象、模板等进行，所以最终这样的代码腐化的非常严重。
代码呈现

public AdjustAssetOrderEntity acceptAdjustAssetApply(AdjustAssetApplyEntity adjustAssetApplyEntity) {
    // 1. 参数校验
    this.parameterVerification(adjustAssetApplyEntity);
  
    // 2. 查询申请单数据，如已经存在则直接返回
    AdjustAssetOrderEntity orderEntity = queryAssetLog(adjustAssetApplyEntity.getPin(), adjustAssetApplyEntity.getAccountType(), adjustAssetApplyEntity.getTaskNo(), adjustAssetApplyEntity.getAdjustType());
    if (null != orderEntity) {
        log.info("pin={} taskNo={} 受理申请，检索到任务存在进行中的申请单。", adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getTaskNo());
        return orderEntity;
    }
  
    // 3. 以下流程放到分布式锁内处理【避免相同请求二次进入】
    String lockId = genLockId(adjustAssetApplyEntity.getAdjustType(), adjustAssetApplyEntity.getUserId());
    try {
        // 3.1 分布式锁：加锁
        long state = lock(lockId);
        if (0 == state) {
            throw new AccountRuntimeException(BizResultCodeEm.DISTRIBUTED_LOCK_EXCEPTION.getCode(), "分布式锁异常，当前用户行为处理中。");
        }
      
        // 3.2 账户查询
        UserAccountInfoDTO userAccountInfoDTO = queryJtAccount(adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getAccountType());
      
        // 3.3 基础校验：(1)账户类型、(2)状态状态、(3)额度类型、(4)账户逾期、(5)费率类型【暂无】
        LogicCheckResultEntity logicCheckResultEntity = doCheckLogic(adjustAssetApplyEntity, userAccountInfoDTO,
                DefaultLogicFactory.LogicModel.ACCOUNT_TYPE_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_STATUS_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_QUOTA_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_OVERDUE_FILTER.getCode()
        );
      
        if (!AssetCycleQuotaAlterCodeEnum.E0000.getCode().equals(logicCheckResultEntity.getCode())) {
            log.info("userId={} taskNo={} 规则校验过滤拦截。code:{} info:{}", adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getTaskNo(), logicCheckResultEntity.getCode(), logicCheckResultEntity.getInfo());
            throw new AccountRuntimeException(logicCheckResultEntity.getCode(), logicCheckResultEntity.getInfo());
        }
      
        // 3.4 受理调额
        return this.acceptAsset(adjustAssetApplyEntity, userAccountInfoDTO);
    } finally {
        // 3.1 分布式锁：解锁
        this.unlock(lockId);
    }
}