DDD领域驱动设计模型的理解和学习——一种很厉害的架构思想

一、什么是DDD

领域驱动设计,是一种架构思想。以领域模型为核心,强调在代码中体现领域的思想,开发人员和领域专家一起进行系统建设。没有一种稳定的技术框架,DDD要求领域跟技术、存储、通信无关。
解决系统老化,防止系统老化。

大泥团:不利于微服务的拆分。大泥团结构拆分出来的微服务依然是泥团机构,当服务业务逐渐复杂,这个泥团又会膨胩成
为大泥团。

面向业务来建立领域模型,比如商品领域、物流领域。
MVC架构-》领域优先的四层架构:
在这里插入图片描述

二、系统老化的原因

1.需求难,越来越难实现,系统越来越复杂,需求也很难提。
2.开发难,一个类上千行代码,这段代码有什么功能?能不能去掉?越来越难开发。
3.测试难,没办法单元测试,一个小需求需要回归测试,工作量变大。
4.创新难,新技术越来越多,老系统重构要花的时间越来越多,越拖越烂。

三、高质量代码的标准

高内聚、低耦合,考虑代码的可维护性、可测试性、可扩展性。
单一职责原则:每个功能模块只做单一的事情。
开放封闭原则:对扩展开放,对修改封闭。
依赖反转原则:依赖接口,而不依赖实现类。

四、DDD基础概念

4.1实体、值对象

实体承载业务:实体类里面放业务相关的属性和业务方法,每个实体的业务要求清晰。
业务是造成实体状态变化的动作,比如:转账,造成了账号(实体)的金额(实体的属性、状态)发生变化。
特别的,业务是不包含在数据库的查询,增删,保存。数据库的增删改查不影响实体状态的变化。

值对象:
order->orderItem->Address
整体和部分的关系,就是实体和值对象的关系。如果订单不存在了,订单表和地址就没有意义了。

好处:入口单一,当访问值对象的业务时,要从实体访问。

4.2贫血模型

实体+业务方法=充血模型
POJO=贫血模型
贫血模式就是类里面只有成员变量和get、set方法。
贫血模型的问题:不知道这个POJO对象实体以前的业务有哪些逻辑(贫血失忆症)

4.3仓库和工厂

仓库repository:放着一个对象池,放着我们业务需要的所有对象和数据。
工厂factory:组装复杂对象,组装从数据库拿的数据。

4.4防腐层

防腐层ACL:隔离第三方的依赖,防止第三方业务的变化影响自己的业务。
对第三方接口的返回值进行一个结果集的封装。

4.5基础设计层

系统内调用的基础组件比如mq,可以将方法脱构,类脱构。

4.6领域服务

每个实体只能操作自己的属性,而跨实体的操作,需要抽象成领域服务,专属于当前领域使用的服务。只能调用领域的业务方法,比如转账业务。

4.7聚合

当有多个领域相同,领域与领域之间进行交互会形成一个一个聚合。在每个聚合里面会形成一个固定的聚合根。比如一个领域两个是实体,在两个实体里面聚合会指定一个聚合根,对聚合内对象的访问必须经由聚合根对象。

五、DDD优点

1、需求更容易梳理:业务逻辑清晰纯净, 没有业务与实现细节之 间的复杂转换。
2、业务更容易开发:各领域内完全自治, 不用担心其他模块的影响。
下单模块的Account与账务管理模块的Account属性与方法都可以完全不同,没有任何直接关联。
3、更容易单元测试:业务与外部依赖完全隔离,各功能组件的依赖也都是独立的。
很容易设计单元测试案例,单独测试。
4、技术容易更新:所以实现细节都是业务逻辑的扩展,指哪改哪。对业务无影响。

六、DDD四层架构规范

1、领域中的对象由实体和值对象组成。对值对象的访问必须经由所属的实体对象。
2、相关联的一组实体与值对象组成聚合。对聚合内对象的访问必须经由聚合根对象。
3、跨实体的操作必须经由领域服务。
4、应用服务层只通过领域服务或者聚合根来组织业务,自身不带任务实现逻辑。
5、业务与数据隔离。领域层只关注业务,数据支撑全部交由基础设施层。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

爱喝皮蛋瘦肉粥的小饶

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值