DDD设计思想及例子

DDD设计思想

软件核心复杂性，本质要对业务拆分的复杂性进行梳理
架构思想（不要一直重构了）
之前架构三层架构（MVC）controller,service,dao
DDD架构四层架构风格:
用户接口层 User Interface: 负责与用户进行交互，解释用户请求，返回用户响应，只依赖与应用层
领域层 Domain Layer（实体对象，系统核心，纯粹表达业务能力，无外部依赖）
应用服务层 Application Layer: 协调领域对象，组织形成业务场景，只依赖领域层
基础设施层 Infrastructure Layer: 业务与数据分离，为领域层提供持久化机制，为其他层提供通用技术能力（数据库，缓存，api)

在这里插入图片描述

例子：模拟服务开放平台

服务开放平台（将自己的业务能力向互联网开放，如微信，支付宝，快递等开放平台）
客户端注册到第三方开放平台中去获取想要的接口能力，开放平台接入其他平台的服务，第三方平台注册到开放平台（系统的id[辨识第三方系统],名称,消息推送路径）（开放平台集成其他平台的服务，将结果返回给第三方平台）统一开放给第三方平台使用一些能力，客户端注册到第三方开放平台中去获取想要的接口能力
流程：其他系统注册到自己的开放平台获取公钥，根据公钥加密调用开放平台接口，
开放平台接口鉴权解析去调用后端的微服务接口，回调接口将结果推送到其他平台预留的结果推送地址

在这里插入图片描述

例子：模拟服务开放平台–改造前

MVC版的设计路线是优先设计表结构，通过UML图、时序图等工具，优先设计出能够支撑业务的表结构。然后再从Controller开始实现接口，Service实现业务。
如果业务需要变更，比如项目中，对于第三方系统的ClientInfo表设计，如果后续鉴权系统需要优化，对客户端的表述就需要改变。这样就需要改ClientInfo表结构，随之而来就会要改动上层业务，会相当被动。确定表结构后，MVC的通常设计方式会通过很多Service来表现业务，这些Service的数据边界是混乱的，不清晰的。这就会造成后续梳理业务非常困难。后面有更多的能力接入进来之后会有很多if-else会很杂乱
三层MVC架构的缺陷：
1.看起来很像事务脚本，只要改动了其中的东西会一直一直改动代码，耦合性太高
2.可维护性差，大量第三方模块影响核心代码稳定
3.可拓展性差，业务逻辑与数据存储相互依赖，无法复用
4.测试性差，庞大的事务脚本与基础设施耦合，无法单元测试

在这里插入图片描述

例子：模拟服务开放平台–改造后

步骤一：抽象数据存储层
①实体类充血模型（将对对象的操作（对属性状态变化的方法）也放到实体类中，不止字段）
②设置抽象类和实现类，负责实体和数据库交互（仓库），摆脱数据库限制
此处实体和数据库不一定要一一对应，因为中间有实现类可以操作，而且可以替换不同的数据库实现存储
③设置防腐层，隔离外部服务，使用接口和实现类的方式设置service服务，封装第三方组件，便于扩展，便于与第三方交互
④抽象变动比较多的地方设置接口，实现类，封装跨实体的业务，去调用类中已经定义的变动方法
每个组件的功能都是独立的，如果要调整对应的组件即接口和实现类，调用的原代码不需要大量修改
步骤二：构建领域地图
本质是服务的边界隔离，限界业务能力，形成独立的结构（包结构，项目模块，微服务）
不同领域模块只能调用其暴露的接口放到此领域的包中(adaptor)，java 采用接口和实现类的方式
每个领域内使用四层架构（entity,infrastructure,repository,service），根据业务去划分而不是技术，不同领域用相同的结构去构建4层架构
技术层面尽量用同一个语言，结构去构建，便于构建统一描述各个组件的内容
单体架构实现：在resource下建META-INF.service包配置上服务的实现类路径，java通过spi机制去扫描获取到这个服务
每个服务如此，如果有新接入的功能也不需要改变原来服务的代码，只需要放一个新的服务jar包，(原服务入口根据传入的
微服务架构实现：通过nacos注册的名字用feign远程调用-微服务架构)
单体架构优先，每个业务都清楚了之后慢慢拆分成微服务，这俩结构是可以进行转换的，前提是合理对业务服务进行隔离（java中基于接口隔离）
由单体架构的直接引用–>微服务的远程调用
DDD可以实现项目在单体架构和微服务架构之间相互切换（用不同的注解，spi机制使用单体架构引入其他模块 nacos注册中心引入其他模块）