DDD 架构
1.Domain Primitive
接口的清晰度（可阅读性）：混乱
数据验证和错误处理：大量重复
业务逻辑代码的清晰度：胶水代码，逻辑混乱，校验业务耦合
可测试性：无法单独测试
隐性的概念显性化：如将用户，地址，金钱信息显性化，独立行为，独立维护，拆分数据校验等
--值对象抽离，实体Entity+值对象Entity聚合，---不变性，无状态（共享值对象），专享实体
2.应用架构
独立与框架
独立于UI
独立于底层数据源
独立于外部依赖
可测试
可维护性，可拓展性，可测性--问题
基础设施层Repository和Entity：dao
第三方服务-防腐层：适配器，缓存，兜底，降级，易于测试
封装业务逻辑：贫血模型，充血模型
贫血模型：坏处：调用方逻辑，重复率极高，健壮性差；为什么出现：面向数据库编程CRUD，简单，流水代码，好写但不好维护；
举例：MVC如果做缓存，怎么做？优化层级，以及模型DO Entity DTO
3.领域层设计规范
行为抽离，组件化，数据驱动
事件模型：生成，存储，分发，消费
领域事件：通过行为抽离，
4.接口层
调用来源，统一鉴权，限流，统一异常
CQE对象
不要有业务逻辑，做业务流程串联就好
可维护性高 当外部依赖变更时，内部代码只用变更跟外部对接的模块，其他业务逻辑不变(数据
迁移时主键的处理与屏蔽、缓存处理)。 边界清晰，各个层之间只依赖领域层的接口，不依赖具体实现。 基础设施层与应用解耦，方便基础设施层依赖库的升级。
可扩展性强
做新功能时，绝大部分的代码都能复用，仅需要增加核心业务逻辑即可。 数据来源多样性，基础设施层负责从各个渠道获取数据(数据库、缓存、消息队列)
兼容不同的数据格式。 同时基础设施的层出现可以将更新收口，方便后期升级更换数据源(加入数据缓存服
务等)。 可测试性高
每个拆分出来的模块都符合单一性原则，绝大部分不依赖框架，可以快速的单元测试
做到 100%覆盖。 当代码中强依赖了数据库、第三方服务、中间件等外部依赖之后，想要完整跑通一个
测试用例需要确保所有依赖都能跑起来，这个在项目早期是及其困难的。良好的分层可以 mock 数据快速单独测试。
代码结构清晰
通过 POM module 可以解决模块间的依赖关系，
基础平台目前 DDD 应用现状:
- 支持独立部署与混合部署，
- 各个域之间 通过接口依赖，单独学习某一个的成本低
- 可拓展性好，预留拓展接口(缓存、ES)
- 可测试性高，各层解耦，可单独测试
网友评论