了解Spring Web应用程序体系结构：经典方法

每个开发人员必须了解两件事：

架构设计是必要的。
花哨的体系结构图没有描述应用程序的真实体系结构。

真正的体系结构是从开发人员编写的代码中找到的，如果不设计应用程序的体系结构，最终将得到一个具有多个体系结构的应用程序。

这是否意味着开发人员应由建筑师统治？

不行建筑设计是太重要了，不能留给建筑师，这就是为什么每一个开发商 ，谁愿意不仅仅是一个类型的作家， 一定要做好它 。

让我们从两个原则入手，这两个原则将帮助我们为基于Spring的Web应用程序设计更好，更简单的体系结构。

优秀建筑的两大Struts

建筑设计可能感觉像是一项艰巨的任务。这样做的原因是，许多开发人员被教导要相信建筑设计必须由神秘知识的守护者来完成。这些人称为软件架构师。

但是，任务本身并没有听起来那么复杂：

软件体系结构是软件系统的高层结构，是创建这种高层结构的准则，也是该结构的文档。

尽管经验确实可以帮助我们创建更好的架构，但是架构设计的基本工具实际上非常简单。我们要做的就是遵循以下两个原则：

1.关注点分离（SoC）原则

关注点分离（SoC）原则指定如下：

关注点分离（SoC）是一种用于将计算机程序分为不同部分的设计原理，这样每个部分都可以解决一个单独的关注点。

这意味着我们应该：

确定我们需要注意的“问题”。
确定我们要在哪里处理它们。

换句话说，该原理将帮助我们确定所需的层以及每一层的职责。

2.保持简单愚蠢（KISS）原则

保持简单愚蠢（KISS）原则指出：

如果大多数系统保持简单而不是变得复杂，则它们的工作效果最佳。因此，简单性应该是设计的主要目标，并且应避免不必要的复杂性。

这个原则是理性的声音。它提醒我们，每个层都有价格，如果我们创建一个复杂的体系结构而具有太多的层，则价格会太高。

换句话说， 我们不应该设计这样的架构 ：

来源： Geek and Poke：足迹 – 根据CC 3.0许可

我认为约翰，朱迪，马克和戴维犯有手淫罪 。他们遵循关注点分离原则，但忘记了最小化其体系结构的复杂性。可悲的是，这是一个常见的错误，并且价格很高：

添加新功能比原先需要的时间长得多，因为我们必须通过每一层传输信息。
维护应用程序是不可能的事，因为没有人真正了解架构，并且每次做出的临时决定都会堆积起来，直到我们的代码库看起来像是一大堆东西，有十层。

这就提出了一个明显的问题：

什么样的架构可以很好地为我们服务？

每个人都应该做到三层

如果考虑Web应用程序的职责，我们注意到Web应用程序具有以下“问题”：

它需要处理用户的输入并将正确的响应返回给用户。
它需要一个异常处理机制来向用户提供合理的错误消息。
它需要一个事务管理策略。
它需要同时处理身份验证和授权。
它需要实现应用程序的业务逻辑。
它需要与使用的数据存储和其他外部资源进行通信。

我们可以通过仅使用“三层”来满足所有这些问题。这些层是：

Web层是Web应用程序的最上层。它负责处理用户的输入并将正确的响应返回给用户。 Web层还必须处理其他层引发的异常。因为Web层是我们应用程序的切入点，所以它必须注意身份验证并充当防范未授权用户的第一道防线。
服务层位于Web层下方。它充当事务边界，同时包含应用程序和基础结构服务。 应用程序服务提供服务层的公共API。它们还充当交易边界并负责授权。 基础结构服务包含“管道代码”，该“管道代码”与外部资源（例如文件系统，数据库或电子邮件服务器）进行通信。通常，不止一个应用程序服务会使用这些方法。
存储库层是Web应用程序的最低层。它负责与使用的数据存储进行通信。

属于特定层的组件可以使用属于同一层或其下一层的组件。

经典的Spring Web应用程序的高级体系结构如下所示：

接下来要做的是设计每一层的接口，这是我们遇到诸如数据传输对象（DTO）和域模型之类的阶段的阶段。这些术语描述如下：

数据传输对象是一个仅是简单数据容器的对象，这些对象用于在不同进程之间以及应用程序各层之间承载数据。
域模型由三个不同的对象组成：
- 域服务是一种无状态类，它提供与域概念相关但不是实体或值对象的“自然”部分的操作。

现在我们知道了这些术语的含义，我们可以继续设计每一层的接口。让我们一层一层地进行检查：

Web层应仅处理数据传输对象。
服务层将数据传输对象（和基本类型）作为方法参数。它可以处理域模型对象，但只能将数据传输对象返回到Web层。
存储库层将实体（和基本类型）作为方法参数，并返回实体（和基本类型）。

这就提出了一个非常重要的问题：

我们真的需要数据传输对象吗？为什么我们不能仅仅将实体和值对象返回到Web层？

这是一个坏主意有两个原因：

域模型指定了我们应用程序的内部模型。如果我们将此模型暴露给外界，则客户将不得不知道如何使用它。换句话说，我们的应用程序的客户将不得不照顾不属于他们的东西。如果使用DTO，则可以向应用程序的客户端隐藏此模型，并提供更简单，更简洁的API。
如果我们将领域模型暴露给外部世界，那么我们在不破坏依赖于它的其他内容的情况下就无法更改它。如果使用DTO，只要不对DTO进行任何更改，就可以更改域模型。

经典Spring Web应用程序的“最终”架构如下所示：

还有许多未解决的问题

这篇博客文章描述了Spring Web应用程序的经典体系结构，但未提供对真正有趣的问题的任何答案，例如：

为什么X层负责关注点Y？
我们的应用程序应该包含三层还是少于三层？
我们应该如何设计每一层的内部结构？

这样做的原因是简单的：

我们必须学会走路才能跑步 。

本教程的下一篇博客文章将回答这些问题。

翻译自: https://www.javacodegeeks.com/2014/10/understanding-spring-web-application-architecture-the-classic-way.html