分层架构设计

什么是分层架构？

据我所知，层次架构是将项目结构组织成四个主要类别:表现、应用、领域和基础设施。每一层都包含与它所代表的特定问题相关的对象。

表示层包含所有负责向最终用户呈现UI或将响应发送回客户端的类。

应用层包含应用程序满足其功能需求所需的所有逻辑，但同时它不是域规则的一部分。在我使用过的大多数系统中，应用层是一种服务，它通过服务来安排域对象，以满足用例场景。

领域层表示基本领域，在某些情况下主要由领域实体和服务组成。业务规则，比如不变量和算法，应该保存在这一层。

基础设施层包含所有负责技术工作的类，比如在数据库中持久化数据。

要正确实施经典分层架构，有两条重要规则:

1.从表现到基础设施，所有的依赖都在向一个方向发展。

2.与一层的关注点无关的逻辑不应该放在另一层。例如，不应该在用户界面中执行域逻辑或数据库查询。

分层建筑的本质

架构是一个过载的术语，所以我们可能应该在层的上下文中更深入地理解这个术语的实际含义。分层架构背后的主要思想是关注点的分离——正如我们已经说过的，我们希望避免将域或数据库代码与UI内容等混合。将项目分成几层的实际想法表明，应该将重点放在源代码的组织和实现上。这意味着除了在应该被分离的问题上提供一些指导之外，层次架构没有告诉我们任何关于项目的设计和实现的事情。这意味着我们应该用其他架构过程来补充它，比如一些初步设计、日常设计会议，甚至成熟的领域驱动设计。我们选择哪一个选项并不重要，至少对于分层来说是如此，但是我们需要记住:分层架构只为我们提供了如何组织源代码的指导。

实施分层架构

有了要创建的层的知识、它们的关系和架构的性质，我们就可以实现它了。正如你们大多数人所期望的，我们将通过为每个系统创建一个单独的包来将系统分成多个层。当应用依赖和分离规则时，事情就不那么明显了。您可以尝试将每一层放在单独的Maven模块中，但是要捕捉域和持久性之间的怪异关系并不容易。我通常坚持使用软件包，并使用常识和代码审查来确保没有违反规则。

分层架构的优势

尽管你们中的一些人可能还不相信，但分层架构有一些好处，包括:

简单——这个概念非常容易学习，从一开始就可以在项目中看到。

在不同的项目中保持一致，因此每个层次项目中的整体代码组织几乎是相同的。

保证关注点的分离——只是关注点是分层的，并且遵守分层架构的规则，但是隐式的代码组织非常容易。

从技术角度来看，可浏览性——当你想改变给定类型的某些/所有对象时，很容易找到它们并把它们放在一起。

分层架构的缺点

当然，分层架构并不完美。它的一些缺点包括:

没有内置的可扩展性——当项目增长过多时，你需要找到一把钥匙来进一步组织自己。分层架构的原理对你没有帮助。

隐藏的用例——你不能仅仅通过查看代码组织来判断项目在做什么。至少你需要读类名，不幸的是，有时甚至是实现。

低内聚力——组成通用解决方案和业务概念的类彼此相距甚远，因为项目是围绕独立的技术问题组织的。

没有依赖的反转——在传统的层次结构中，依赖是直接的。从概念上讲，从较低的基础设施层做出的更改可以传播到更重要的较高层。

何时应用分层架构？

首先，我想写一些我自己使用层次架构的案例，但我认为我们可以根据其优缺点使用更系统的方法:

简单:这显然对每个人都很重要。不存在的学习曲线让它特别适合那些没有经验的团队，很容易申请到没有预算的项目去投资更高级的架构。

一致性:同一批人处理的多个小项目，比如微服务的内部架构。

关注点分离:没有经验的团队。

技术可浏览性:在某种程度上，它帮助了所有人。这取决于你在某个特定的时刻试图寻找什么。

没有内置的可伸缩性:较小的项目应该保留，较大的项目可以很容易地分解成较小的部分。

隐藏的用例和低内聚性:没有或很少复杂业务场景的项目，例如CRUD操作或简单的REST服务。

无依赖反转:一个对基础设施几乎没有依赖的项目，在这个项目中，它实际上可以扩展到一个更高的层次，而不会有严重的底层变化。

摘要

如您所见，分层架构有其光明和黑暗的一面。对我来说，它的简单性和一致性使得它非常适合不需要太多严肃的业务逻辑的微服务。人们可能会质疑这样的微服务一开始是否应该存在，但考虑到大规模整体的现实往往会让它们不那么邪恶。您应该从本文中学到的最重要的一课是，分层架构是关于组织代码以很好地分离关注点，但实际上没有别的。

最后，经过这么多年的发展，我也总结了一套学习Java的资料和面试问题。如果你想在技术上提升自己，可以关注我，私信领取资料或者在评论区留下联系方式。有时间记得帮我点击转发给更多人看。