传统MVC架构

DDD架构：

api层：api请求方式，透传【传递参数】，几个业务对应api

业务层：做编排，业务里要有哪些服务，执行顺序是什么，以及怎么做

领域层：负责领域内调用，然后领域怎么划分

Dao层：数据库操作【或者另外一个应用 数据源之类的】

遵守原则：

①允许跨层调用

②业务细节放在领域层，业务层负责编排，一行一行对应着一个调用，最好不要有其他代码了

③领域层禁止互相调用，可以从包名入手，直接对领域进行分割，就算代码冗余也没事。

④事务管理：放业务层有大事务风险，放在领域层会有一致性问题的风险

领域层怎么划分？

①将划分好的领域在每个业务中推演一遍，看看效果如何，要多角度尝试，验证划分是否合理

②同一领域在一起，不同领域分开，不管大小

③领域模型中加代码通过SPI， 领域具体实现要用倒置依赖的关系，

④接口语义维护很重要。不同层之间参数传递的转换【转化为业务参数】和收敛【去掉冗余参数】

具体如何划分

①划分出上下文【全局中用到的东西】，把统一的动作相同的逻辑抽象在一起。

②确定哪些实体【唯一标识的类】和值对象【通用的属性 一般不再修改】应该在一起

实体：User【id/时间戳/协议】，还有方法：直接存在于实体中比如一些画图方法xxx，xxx方法

值对象：偏向于属性，Property【udp/tcp/http】，方法：协议传递的包数，传递的字节数

每个方法就是他可以做出的行为

③语义区分：同样的属性不同的含义，聚合根【VO/DO/BO整合】

④领域之间有防腐层，对参数进行转换，传递的参数叫做聚合根【VO/DO/BO整合 有实体和值对象】

聚合范畴，如何聚合：确定哪些实体和属性应该在一起

聚合根用在上下文传递过程中，会通过防腐层进行参数转换，语义也会发生变化，直到输出。

补充：

资源层：集成到实体和值对象中和聚合根中，提供数据获取的服务。