CSDN_LiMingfly的博客

D:领域编排【可选】 - case：领域编排层，一般对于较大且复杂的的项目，为了更好的防腐和提供通用的服务，一般会添加 case/application 层，用于对 domain 领域的逻辑进行封装组合处理。功能实现中，如果看到有现成的接口，直接拿来复用。B:接口定义 - api：因为微服务中引用的 RPC 需要对外提供接口的描述信息，也就是调用方在使用的时候，需要引入 Jar 包，让调用方好能依赖接口的定义做代理。而后，进行规则引擎的调用和处理，根据不同的诉求，开发不同的规则，并配置的方式进行使用。

但随着微服务的演进，越来越多的内容被填充到工程中，这个时候你细心的查看架构，就会发现原本的 MVC 结构其实已经变的非常混乱了。统一的异常、数据库的连接、日志的打印、外部服务的调用、消息的监听、任务的轮训以及服务的实现等一些列的东西要处理，分配到不同的工程包下承载。通用的、配置的、组件的、持久化的、内部的、外部的，在以往的单体应用时代开发下，其实是没有这么多东西的，那时候的工程结构都偏向于 Service + 贫血模型实现。这样你所有的通用配置，又和业务没有太大的关系的，就可以直接写到这里了。

工程的建模的目的是为了我们做工程开发时提供指导方案，就像一栋大楼的设计蓝图一样，也像一个超市中会有不同品类的货架，需要提前规划好。在 DDD 中用于完成用户的行为命令和动作分析的过程，是一个四色建模的过程，也称作风暴模型。在使用 DDD 的标准对系统建模前，一堆人要先了解 DDD 的操作手段，这样才能让产品、研发、测试、运营等了解业务的伙伴，都能在同一个语言下完成系统建模。想象下，一个男人，得到了老婆的"命令"，去大超市拿着空的购物车，推进去一圈圈的走，最终完成购物打车回家。C:最终购物完成后，打车回家。

B:换到充血模型下，现在我们以一个领域功能为聚合，拆分一个领域内所需的 Service 为领域服务，VO、Req、Res 重新设计为领域对象，DAO、Redis 等持久化操作为仓储等。一套账户服务中的，授信认证、开户、提额降额等，每一个都是一个独立的领域，在每个独立的领域内，创建自身领域所需的各项信息。最能体现这样设计的就是仓库和适配器的设计。仓储解耦的手段使用了依赖倒置的设计，所有领域需要的外部服务，不在直接引入外部的服务，而是通过定义接口的方式，让基础设施层实现领域层接口（仓储/适配器）的方式来处理。

1：用户发起 HTTP 请求开始，Controller 在接收到请求后，调用由 Spring 注入到类里的 Service 方法，进入 Service 方法后有些逻辑会走数据库，有些逻辑是直接内部自己处理后就直接返回给 Controller 了。而架构设计的意义更多的就是在解决系统的反复的维护和迭代时，如何降低成本，这也是架构分层的意义所在。所以，为了不至于让一个类撑到爆💥，需要把黄色的对象、绿色的方法、红色的接口，都分配到不同的包结构下。B:common 是额外添加的一个层，用于定义通用的类。