领域驱动设计DDD

最近看了领域驱动设计，斗胆粗浅聊聊我的看法：
1. DDD演进了三层架构presatition-Application层（也可以叫service层、逻辑业务层BLL层)-DAL层（也可以叫Infra等），由于application层逻辑过多，后期维护容易像面条一样缠在一起，数据耦合混乱，引入DDD层 依赖反转将数据流清晰，开发熵增慢。对于这一层的设计，将外部所有依赖都反转依赖DDD层，对层的设计，延伸出来了很多概念，entity-value object-domain service，用来定义DDD层的零件；aggregate-factory-repository用来规范对象的增(factory)删改查（aggregate）与持久化(repository）。
2.架构通过文件系统（文件夹、命名）以模块化的形式展现，对应到具体的实践，DDD层以domain文件夹声明，domainService以命名*Manager声明等。
2.业务演进模型会变得更加复杂、为了将层与层、模型与模型之间（拆分出界限）之间进行区分，又引入了限界上下文-上下文映射-域等概念；层与层之间需要通信，通过共享内核（shared）、防腐层（ACL）等进行通信。
4.架构有很多书籍、很多架构形状，本质都在说同一件事情：引用《整洁架构的》观点，基于多态实现抽象接口，实践依赖反转的原则，忽略外部细节。
5.架构设计-架构模式-设计模式，维度层层变小。DDD、整洁架构等一类思想启蒙类、内在审美类的书籍归类架构设计；微服务-六边形等属于具体的架构模式，是对思想和设计的实现；设计模式指的是GoF 23种设计模式又是具体架构模式的局部细节抽象，维度就更低了。
#牛客AI配图神器#