Spring项目的按层打包已过时

我认为Spring应用程序不应该以逐层方法构建。 在我看来，按功能打包更有意义。

首先，让我简要描述每种方法。

“按层打包”（在非Java世界中为“按类型折叠”）

该项目结构根据源代码文件所属的体系结构层将它们分为包/目录：

.
└── net
    └── lkrnac
        └── blog
            ├── Application.java
            ├── persistence
            │   ├── ProjectRepository.java
            │   └── UserRepository.java
            ├── dto
            │   ├── ProjectDto.java
            │   └── UserDto.java
            ├── model
            │   ├── Project.java
            │   └── User.java
            ├── service
            │   ├── ProjectService.java
            │   └── UserService.java
            └── web
                ├── ProjectController.java
                └── UserController.java

“按功能打包”（非Java世界中的“按功能折叠”）

另一方面，此方法将属于系统内某些功能的文件组合在一起：

.
└── net
    └── lkrnac
        └── blog
            ├── Application.java
            ├── project
            │   ├── ProjectController.java
            │   ├── ProjectDto.java
            │   ├── Project.java
            │   ├── ProjectRepository.java
            │   └── ProjectService.java
            └── user
                ├── UserController.java
                ├── UserDto.java
                ├── User.java
                ├── UserRepository.java
                └── UserService.java

发展趋势

这个话题使我很久了。 当我用谷歌搜索“按层打包”还是“按功能打包”还是“按类型打包”还是“按功能打包”时，“按功能”结构的支持者似乎越来越多。 我也在这个营地。

但是不仅应用程序开发人员是它的支持者。 Angular（最著名的单页应用程序框架之一）正在其样式指南中推广此类文件夹结构。

Spring项目结构

由于有很多关于每种方法的利弊的文章，我将重点介绍对Spring项目的影响。

放下Spring CRUD应用程序的传统结构（如果您的后端应用程序未使用Spring Data REST）分为三层：Web /服务/持久性。 我从事的大多数Java / Spring项目都遵循这种结构。

耦合

逐层封装很可能起源于上个世纪，在那里分层结构被用作去耦机制。 实际上，当我挑战逐层结构时，“去耦”通常是答案。 我不同意。 对我来说，逐层封装是导致紧密耦合的主要原因之一。

在逐层结构化项目中为类编写签名时，第一个关键字是什么？ 我敢打赌这是公开的。 公共访问修饰符是否有助于解耦？ 我想没有人会回答 是这个问题。

为什么开发人员到处使用公共访问修饰符？ 正是因为该项目是以分层方式构造的。 存储库类需要是公共的，因为它需要从服务包中进行访问，而服务也必须是公共的，因为它需要从Web包中进行访问。 当一切都公开时，很难保持纪律，不会导致大的泥潭。

使用按功能打包时，私有UserRepository程序包（这意味着未指定访问修饰符）不能由UserService以外的其他服务使用，因为它们在同一程序包中。 而且，如果我们决定仅UserController应该使用UserService，则将其打包为私有，因为它们共享同一包。 在这样的项目结构中，大多数类都是包私有的。 因此，开发人员应该有充分的理由公开课堂。

缩放比例

如果项目在Web /服务/持久层中开始具有10多个类，会发生什么情况？ 开发人员倾向于将类分组为子包。 但是，他们如何对它们进行分类？ 根据我的经验，它主要基于功能。 因此，我们经常可以在较大的项目中找到这样的结构：

.
└── net
    └── lkrnac
        └── blog
            ├── Application.java
            ├── dao
            │   ├── ...other repositories...
            │   ├── ProjectRepository.java
            │   └── user
            │       ├── UserRepository.java
            │       └── UserRoleRepository.java
            ├── dto
            │   ├── ...other DTOs...
            │   ├── ProjectDto.java
            │   └── user
            │       ├── UserDto.java
            │       └── UserRoleDto.java
            ├── model
            │   ├── ...other models...
            │   ├── Project.java
            │   └── user
            │       ├── User.java
            │       └── UserRole.java
            ├── service
            │   ├── ...other services...
            │   ├── ProjectService.java
            │   └── user
            │       ├── UserRoleService.java
            │       └── UserService.java
            └── web
                ├── ...other controllers...
                ├── ProjectController.java
                └── user
                    ├── UserController.java
                    └── UserRoleController.java

这不是明显的疯狂吗？

未来的证明

正如一群聪明人所建议的那样， 从微服务架构开始绿色领域项目可能不是一个好主意 。 我同意。 因此，如果您的应用程序Swift增长，则准备好整体以最终分成较小的项目可能是个好主意。

想象一下，您将需要从整体项目中提取微服务。 或将整个项目拆分为微服务。 我希望每个人都明白，没有理智的微服务架构被架构层分开。 使用基于特征的分离。 那么哪种项目结构将更容易划分为微服务？ 一个，其中任何公共类都可以使用任何包中的任何其他公共类（逐层打包）？ 还是一个，分成多个包专用存储桶（按功能打包）？ 我相信答案是显而易见的。

结论

按功能打包是一种简单但非常强大的去耦机制 。 因此，下一次某位痴迷的开发人员将作为解耦机制逐层捍卫项目结构时，请纠正她/他的误解。 我认为恐龙化是当今仍然存在逐层包装的唯一原因。

翻译自: https://www.javacodegeeks.com/2018/02/package-layer-spring-project-obsolete.html