一、整洁架构分层
整洁架构分层如图所示，从内到外分别为实体->用例->接口适配器->框架与驱动程序。其中实体层和用例层包含业务逻辑、接口适配器层是翻译层，负责把外部数据翻译成业务层能够识别的结构、框架与驱动程序负责各种IO。
二、DDD分层
六边形分层
1、我们最初落地的DDD分层架构如下图所示，这种分层结构类似于六边形架构，本质上把代码分成了2层，一层是业务逻辑和业务逻辑依赖的接口、另一层是接口的具体实现和数据库、框架等细节。
2、在这种DDD分层架构中，内层圆代表业务逻辑层，其中实体、值对象、聚合、领域服务等都对应于整洁架构中的实体层；应用服务层对应的是整洁架构中的用例层。
3、这种分层结构的缺点是不完全符合整洁架构要求的插件式架构，虽然我们可以把appliation层和domain层整体打包，适配不同数据库、前端、框架等。application层和domain层中的domain service不包含业务逻辑，只包含接口，这些业务逻辑还需要再实现遍。
整洁分层
1、由于我们项目是toB项目，不同甲方公司对数据库、前端、框架等这些技术要求可能不一致，比如有的公司要求使用mysql、有的公司要求使用oracle。但是业务逻辑是基本一致的，这非常符合插件式架构，于是我们对架构做了改进。
2、等等，看起来和上面的一样？嗯，整体上图差不多，区别在细节上，application和domain层里的应用服务和领域服务包含了具体实现，只有服务具体实现有其他依赖的时候才引入这个依赖的接口，而不是整体把应用服务和领域服务的实现类放到infrastructure里面。
3、整洁架构里有一个老大难问题，就是事务的处理。我们一般会在application层中处理事务，原来六边形架构的时候application层的实现是在infrastructure里，是可以依赖spring的，方法上直接加个@Transactional注解就行；但是整洁架构中要求application层即要有业务逻辑实现，又不能依赖spring等框架，所以事务的处理和依赖关系管理变得困难。
- 解决方案：关于依赖关系注入我们可以在infrastructure或者starter启动模块里通过@configuration进行注入。关于事务管理我们可以借用spring手动提交事务，然后借助注解和切面实现新的事务注解，这样application就即包含业务逻辑又可以处理依赖关系和事务了。
4、此时我们可以说实现了比较全面的插件式架构，我们可以单独交付domain层，然后去实现一个符合该公司业务场景的application层及技术细节层。有的公司业务场景有可能和我们实现的重复，那么我们又可以把domain层和application层一起交付，只需要按照该公司技术要求来实现技术细节。对于没有技术要求，且场景也重复的公司，我们可以直接交付完整项目。
三、实现细节
1、数据库是实现细节
- DDD设计中我们是从domain出发，推后设计表结构
- 假如内存无限大、永不宕机，那么我们只设计对象数据结构，不用考虑数据库，所以数据库是关乎磁盘的IO
2、web是实现细节
- DDD设计中不会首先考虑UI等的数据结构，推后通过cqrs直接查表翻译成DTO、或者领域对象翻译成DTO，所以UI数据结构设计可能比表设计还要靠后
- Web本质上是一种网络IO
3、应用框架是实现细节
- 框架如spring主要用来管理依赖关系，管理事务等，当我们引入框架后，如果没有做特殊管理，后来人可以很随便的把各种工具类、template类等引入到业务代码中，导致依赖关系混乱
- 框架升级可能导致我们依赖不需要依赖的东西，违背单一职责
- 未来可能切换到更好的框架，而切换一定会影响业务逻辑
4、各种redis、kafka、es等中间件也是技术细节
- 这些本质上都是网络IO
- 版本升级等都会影响业务逻辑
