- veiw/controller：展示/控制层；用于接收校验请求与返回
- service：编写主要业务逻辑
- dao:提供数据库访问接口
总结
MVC与三层架构没有关系。
硬要说有关系，那就是SSM框架下的三层架构中，从controller开始全部都是M，SpringMVC充当了C。因为前后端分离，V已剥离给了前端。
DDD的架构的演进
Entity-Boundary-Interactor架构（1992年）
Entity: 实体对象，包含数据、行为（充血模型）
Boundary(边界): 系统与外界交互的边界，等价于如controller、dao、consumer等。
Interactor(交互器): 等价于 Application Services（DDD架构中的应用服务层),Domain Services DDD架构中的领域服务层)
总结
EBI架构本身并无重大突破，但其提出了边界概念，确立以实体为核心的理念，为后续的架构演进奠定了基础。
六边形（适配器）架构（2005年）
将EBI的Interactor变成六边形（多边形），将Boundary变成输入输出，我们得到了以下模型。
六边形中有两个重要的概念，端口与适配器。
端口理解为不同的请求协议。如http协议，xxl-job协议，dubbo协议，mq协议。
适配器可以理解为转换协议的组件（包括接口），如springmvc下的controller就是一个适配器。
六边形图一
六边形形图二
在六边形图一的基础上，添加了边界与层级。
最外层的入口适配器是应用程序的最外层边界
第二层是业务边界
最内层是核心业务层
洋葱架构（2008年）
六边形架构强调适配，也被成为适配器模式。为什么要叫六边形不是八边形，我觉得可能和六边形战士一个意思吧
它突出了适配，却只提到了两层，适配层和业务层。还不无法指导落地；
洋葱架构明确了每一层的职责，弥补了六边形架构的缺点
六边形图三
然我们再次优化六边形图二，让其更贴近洋葱架构，得到以下图形
整洁架构（2012年）
整洁架构可以理解为，洋葱架构。因为多部分人都是这么认为的。
两者在分层上没有差异。概念上有所区别。
整洁架构的user cases强调的是场景。严格来说，从整洁架构起，才算领域驱动架构。
若彻底贯彻这个理念那么在appliaction service层将大大减少update,add，get这样没有业务含义的接口。
整洁架构的entities强调实体的核心地位。而domain service只是实体的一个补充。
若domain service过于复杂，则说明entity还不够饱满。
DDD经典四层架构
为了说清楚领域层的依赖倒置，这里贴出“领域层”仓储的部分代码。
可以看到仓储依赖了Mapper,而mapper属于基础设施层（mapper是一个出口适配器）.
与洋葱模型的要求不符———领域层不依赖其他层
@Repository
public class PaymentApplyRepository extends DomainRepository<PaymentApply> {
@Resource
private PaymentApplyMapper paymentApplyMapper;
@Resource
private PaymentApplyDomainConverter paymentApplyDomainConverter;
@Override
public Optional<PaymentApply> findOneById(Object id) {
return Optional.ofNullable(paymentApplyMapper.selectById((Long) id))
.map(p -> paymentApplyDomainConverter.toEntity(p));
}
}
《实现领域驱动设计》中提到的分层架构如左图所示。
我们发现领域层依赖了基础设施层，不符合洋葱架构的的理念。于是将依赖倒置下，如右图。
所谓的依赖倒置就是将仓储代码移到基础设施成。这样就保持了领域的独立性。
你可能会发现，除了经典四层架构能够轻松看懂，其他的架构细细推敲下来都不容易理解。
事件发布接口写在哪一层，监听者写在哪一层，生产者写在哪一层。
洋葱架构中同一层可以相互调用吗？
我们习惯由上而下的架构风格，很难理解其他几种架构。
有人将洋葱架构，六边形架构，经典四层架构结合起来，给出了更符合研发思维的菱形架构。
菱形架构的本质是将领域层的入口和出口，两个方向理解成南北向网关。
调用方式自北而南调用。
虽然南北在module上有隔离，但概念上属于同层。
