DDD应用架构内部分享-没错我又来了

最新推荐文章于 2024-07-15 20:53:41 发布

5ycode

最新推荐文章于 2024-07-15 20:53:41 发布

阅读量400

点赞数

分类专栏： DDD 文章标签： java DDD 领域驱动设计

本文链接：https://blog.csdn.net/f80407515/article/details/120395526

版权

DDD 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

没错，又来了，一个项目的结束，就会复盘并完善下。

传统开发的弊病：

通过事务脚本模式来开发需求；
开发人员热衷于技术并通过技术手段解决问题，而不是深入思考和设计业务的走向；
过于重视数据库，围绕数据库和数据模型进行建模，按数据流程进行建模；
按技术视角进行业务命名，导致后续迭代以及人员更替时，产品和技术无法对齐；
随着业务的发展，到后续业务、技术无法沟通，各种不理解；
业务希望技术出排期，技术得撸代码，耗费精力；
代码开发的过程中技术和业务耦合，一个场景一个服务，代码流水线；
因为技术的问题会导致业务流程的中断，导致异常问题过多；
过度方案太多，没有定期消除，导致后续的代码越来越难维护；
业务只加需求，不减过期的需求，导致软件越来越臃肿；

DDD解决了什么？

通用语言，让开发和业务在语言上统一；
战略设计(业务和开发都能看到的软件模型)
边界划分（通过限界上下文来划分，在不同的情景下域的作用是不同）
领域划分（通过域来确定业务领域，包含核心域、子域、支撑域）
分层架构（整洁架构）
战术设计
聚合（值对象，实体，聚合根）
领域事件

最终要达到的目的：

业务和技术能够通过领域模型建立通用语言（业务和技术的沟通无障碍）；
业务边界清晰（微服务的拆分）；
业务模型独立且模型具备可测试性；
技术实现独立，可以随着业务的发展不断的更迭；

名词解析

事务脚本-面向过程

事务：执行的业务
脚本一组系统执行的操作，和用户的逻辑关联；

根据接口请求，将业务逻辑通过面向过程组织为解决方案的过程；特点：

简单（仅依赖面向对象语言的少量功能）
快速开发快、上线快
扩展性查
改动以后测试性差
业务复杂后，代码容易变成“大泥球”，系统腐化速度和复杂性呈指数级上升

领域模型

通过面向对象的设计，将业务实现模型化（将类的状态和行为分离）；

特点：

还原现实世界（复杂）
责任清晰
边界清晰
完全面向对象，状态和行为分离；
扩展性强
测试性强
简单的业务用领域模型反而复杂了；

如何理解领域？

领域逻辑是显性的专业知识，符合事实逻辑（生活中的事务，必须满足一致性），可以很容易的推导出来；
领域逻辑是提纯、通用的规则，不管我们的业务流程怎么变，我们的领域逻辑是不变的，所以领域一定是正确的，一定是合规的（合理性不由领域控制）；
领域逻辑是稳定的（不易变，易变的规则都应该放到应用层）

就像我们做的会员系统，用户在购买会员的时候

参数校验 application层
防重校验 application层
有支付中的会员订单不能购买（随着业务的变动，易变）application层
会员不能重复购买（随着业务的变动，易变）application层
库存扣减与初始化订单（不变）领域层
支付（支付领域）领域层
会员初始化（不变）领域层

DDD

是对面向对象设计的改进，开发复杂业务逻辑的一种方式，但不是银弹。

特点：

通过领域划分有助于把应用程序分解为服务；
每个服务都有自己的领域模型；
限界上下文清晰

实体

具有持久化ID的对象，能唯一标识一个条记录的；

特点：

标识（identity）唯一不可变,且能区分出具体的事物
连续性（continuity），贯穿整个生命周期
只有根实体对外暴露（但不排除一些为了冗余而暴露别的信息）

在我们的系统里，用户实体的标识:包含id和租户，只有这两个组合我们才能唯一识别出这个用户

public class CustomerId {

    private Long id;
    private Integer tenantId;

    public CustomerId(Long id, Integer tenantId) {
        this.id = id;
        this.tenantId = tenantId;
    }

    public boolean isRealName(){
        if (Objects.isNull(this.id) || this.id == 0L){
            return false;
        }
        return true;
    }
}

值对象

⽤于描述状态的属性，特征，只关心对象是什么，不关注唯一性。

脱离了主体对象就没有任何意义，比如会员的有效期；

public class VipPeriod {

	/**
	 * 当期会员开始时间
	 */
	private Date currentStartTime;
	/**
	 * 当期会员过期时间
	 */
	private Date currentExpiredTime;
	/**
	 * 会员有效连续性的开始时间
	 */
	private Date validStartTime;
	/**
	 * 最终过期时间
	 */
	private Date lastExpiredTime;
	
	public Boolean isVip(){
	    //是否会员判断逻辑
	}
	
	public VipStatus vipStatus(){
	    //获取状态
	}
	//续费会员计算
	public void renew(VipType vipType){
	    //根据不同的会员类型，做不同的计算
	    addMoth();
	}
	//续费月会员逻辑
	private void addMoth(){
	    
	}
	//续费季会员逻辑
	private void addQuarter(){
	    
	}
	//续费季会员逻辑
	private void addQuarter(){
	    
	}
}

聚合根

把一组有相同生命周期、在业务上不可分离的实体和值对象放在一起；

定义了对象之间清晰的关系和边界，实现领域模型的内聚；
必须将聚合根作为一个修改数据的单元（我们是在对应的领域服务中处理）
一个聚合必须有一个聚合根，根是聚合中的一个实体；
对一个聚合中实体的访问或操作，必须通过这个聚合的聚合根开始；（我们的聚合根只有访问，和聚合根的公共方法）
在对聚合进行查询或操作时，整个聚合是作为一个整体；


public class VipEntity {
	/**
	 * 主键id
	 */
	private VipId vipId;
	
	/**
	 * 用户id
	 */
	private CustomerId customerId;
	
	/**
	 *会员类型 
	 */
	private VipType vipType;
	
	/**
	 *会员有效期(开始时间，失效时间)
	 */
	private VipPeriod vipPeriod;
}