DDD框架

DDD框架

参考:
https://www.cnblogs.com/daoqidelv/p/7499662.html
https://www.cnblogs.com/xiaofuge/p/12914870.html
https://www.zhihu.com/question/25089273

DDD（domain driven design领域驱动设计）框架包括
User Interface（门面层）、application（应用层）、domain（业务领域层）、infrastructure（基础设施层）

分类的依据是：越往上，预期变动越频繁；越往下，预期变动越少。
ui (controller,dto,handle,filter)->application(service,impl)->domain(service,impl)->infrastructure()

User Interface

dto：request和response两部分，通过它定义入参和出参的契约
controller：接口访问协议控制器
拦截器，全局异常处理都是属于ui模块

application

service：应用服务，主要访问领域层和公共基础设施层（消息中间件访问外部的服务）
assembler：组装器，将领域对应组装成对应的dto

domain

domain entity：领域实体，具有唯一的业务标识，常用的model，比如帖子
domain value object：领域值对象，不需要唯一的标识，比如帖子的顶置消息，直接采用帖子的id即可
domain factory：复杂领域对象的创建和重建
domain service：领域服务，区别于应用服务，领域服务是业务服务，
domain event：领域事件，消息事件，比如消息通知和订阅，实现性能和解耦
repository：仓库接口，对应的是公共服务的repository impl，这里相当于只关心接口，不关系具体的实现
translator：将持久化对象转成领域对象

infrastructure

repository impl：对domain层repository接口的实现，主要实现对数据库和缓存的访问
checkLogin：权限校验
exception：异常的分类和定义，同事提供异常的处理
transport：与第三方服务的交互
transcation：事务管理，采用spring的事务
logging：日志管理，log4j
message resource：消息资源，spring统一管理

springMVC框架与DDD框架对比

controller，service，dao
1，业务不区分领域，完全依靠service中进行区分，service经常是与数据库对应
2，dao层直接参与到service中，特别是mybatis-plus
3，消息中间件在service中实现
4，model的抽取导致结构不完整，dao和feign可以抽取，但是其他的抽取将导致不必要的麻烦。sf对不同服务进行了api抽取，api存放了service中的对象，导致在service变动对象的时候，api需要更新，另外其他的服务将会加载没有必要的jar。
其实common还存在一些非常大的隐患，在项目中经常会使用同一个类作为接口入参或者一些业务数据的接收或者封装，看起来发挥了common的作用，但是实际上当业务做大后，这个类可能被改得面目全非，如果说不要共用同一个类，那么问题来了，为什么要把类放在common中？common中最好就是存放字段不变的类或者一些工具类，特点是减少重复造轮，但是mvc和领域设计的概念是为了解耦，为了拆，而不是为了合。最佳的框架应该是有分有合，分而不散，合而不强。

这里关于common的抽取问题：https://blog.csdn.net/Amen_Wu/article/details/106709003

落地

每个分层可以抽取一部分到公共的common.jar，防止重复造轮
每个分层之间的访问都是接口访问
原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联
最终的落地方式可以从接口入手，在mvc的框架基础上对service进行拆分功能与逻辑两个模块