Spring MVC 应用架构经典之路

架构设计两大支柱思维：

能够通过分解或者分层进行应用简化

首先分析应用的功能需求

然后决定如何对应用进行分解或者分层

也就是说这个策略会帮助我们将应用如何合理分层，以及每一层应该处理的功能。

要能够让分层的逻辑简单直接

换句话说，不能因为分层反而造成应用变得复杂

一般对于一个网络应用程序，大致包含如下功能：

处理用户的输入内容，然后返回给用户需要的内容

需要对程序中出现的错误返回给用户合理的问题描述

事务处理

进行用户的授权和认证

实现应用程序的业务处理

和数据存储系统以及外部系统进行交互

我们把程序的功能实现分为三层进行处理：

web 层，网络应用程序的最外层，负责处理用户的输入然后返回用户需要的内容；web层要负责异常处理的信息展示；web层是程序的入口，它要作为第一道防线，来对用户进行认证和授权。

service层，它位于web层之下，执行一个事务逻辑完整处理，通常包括应用服务和基础服务。应用服务提供了service层的公共接口，作为事务的完整处理，它也负责授权认证。基础服务负责和外部资源，比如文件系统，数据库系统，邮件服务器，进行数据传输。通常这些服务被多个应用服务所使用。

repository层，网络应用程序的最底层，它负责和数据存储器打交道，增删改，查询等等。

下面要理清层与层之间如何交互，也就是接口如何定义。我们会用到两个术语：DTO数据传输对象和Domain Model业务模型对象。

DTO比较好理解，就是数据的承载对象，负责在层与层中间的数据传递，而业务模型则包含了三种类型：

无状态业务服务对象，提供与业务概念相关但又不属于一个实体或者值对象的一些操作；

实体对象对应于能够在整个生命周期都保持一个唯一标识的对象；

值对象描述一个属性，它没有唯一标识，它的生命周期只能与一个实体对象绑定。

这里会对DTO产生疑问，为什么不能直接传递给web层实体对象或者值对象？

如果传递实体对象到web层，那么web层就必须了解如何使用它们，web层承担了它职责以外的事情；相反如果仅传递DTO,web层的代码看起来会更加简洁清晰。

如果暴露细节给web层，对于业务模型的修改就会受到牵制；如果仅传递DTO,那么只要保持DTO不变，业务模型可以根据需要进行各种程度的更改。

根据以上分析，我们得出最终的架构设计：

以上翻译自：

https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/