Java : 模块化的手段，是通过分层架构来分模块，还是通过功能特性来分模块，就得看你的公司业务是什么了

我们应该用哪一个? 为什么?

模块化是将一个软件系统解耦成多个模块的过程。除了降低复杂性之外，它还增加了系统的可理解性、可维护性和可重用性。在本文中，将提到一些模块化方法。

依据分层架构来分模块

在这个项目结构中，类被放置在它们所属的架构层包中。此方法导致包内的内聚性较低，因为包中包含的类彼此之间的关系并不密切。下面是一个分层包装的例子:

├── com.app
    └── controller
        ├── CompanyController
        ├── ProductController
        └── UserController
    └── model
        ├── Company   
        ├── Product
        └── User
    └── repository
        ├── CompanyRepository   
        ├── ProductRepository
        └── UserRepository
    └── service
        ├── CompanyService
        ├── ProductService
        └── UserService
    └── util

当我们检查这个结构时，我们会看到包之间的高耦合以及包内部的低内聚。由于repository类将在service类中使用，而service类将在controller类中使用，因此包之间发生了高耦合。
此外，有必要对许多包进行更改以实现需求。

“我觉得我必须了解一切，才能帮助别人。——桑迪·梅斯

什么是内聚和耦合?

• 内聚：
  指包成员之间的逻辑关系的程度。成员之间的高度关系确保了包的独立性。低内聚不仅降低了独立性，而且显著降低了可重用性和可理解性。

• 耦合：
  它指的是包/类之间的相互依赖程度。低耦合显著提高了可维护性。如何?由于在一个类中由于需求而进行的更改不会影响到其他类，因此不会出现副作用，并且维护变得更加容易。

包内的高内聚和包之间的低耦合对于一个好的系统设计是必不可少的。良好的系统设计大大提高了系统的可持续性。

那么，我们如何才能做到这一点呢?

按功能特性来分模块

在这个项目结构中，包包含一个特性所需的所有类。通过在同一个包中放置密切相关的类来确保包的独立性。下面给出了这个结构的一个例子:

├── com.app
    └── company
        ├── Company
        ├── CompanyController
        ├── CompanyRepository        
        └── CompanyService
    └── product
        ├── Product   
        ├── ProductController
        ├── ProductRepository
        └── ProductService
    └── util
    └── user
        ├── User   
        ├── UserController
        ├── UserRepository
        └── UserService

这种结构消除了另一个包中的类对一个类的使用。此外，包中的类彼此密切相关。因此，包内部具有高内聚性，而包之间具有低耦合性。

此外，这种结构提供了更高的模块化。如何? 让我们假设还有另外10个domain，而不仅仅是Company、Product和User。在按层包中，控制器、服务和存储库被放置在不同的单个包中，因此整个应用程序由三个包组成——除了util——并且包有大量的成员。然而，在按功能包的风格中，同一个应用程序由13个包组成，因此，模块化得到了提高。

如果一个特性可以在一次操作中删除，那么应用程序就具有最大的模块化。

按功能特性分模块的优点

• 如前所述，按功能特性分包具有高内聚、低耦合和高模块化的包。
• 按功能特性分包允许一些类设置他们的访问修饰符Package - private而不是public，所以它增加了封装。另一方面，按层打包迫使您将几乎所有类设置为public。
• 按功能分包减少了在包之间导航的需要，因为一个功能所需的所有类都在同一个包中。
• 按功能包类似于微服务架构。每个包仅限于与特定功能相关的类。另一方面，按层封装是单一的。随着应用程序规模的增长，每个包中的类数量将不受限制地增加。

结论

正如Martin Fowler所建议的，用微服务架构开始一个新项目可能不是一个好主意。如果您的应用程序实现了重大增长，并且其界限是确定的，那么迁移到微服务架构可能是一个好主意。

让我们想象一下上面的情况，您决定从您的单体项目中提取微服务。既然微服务是基于功能的，那么哪种结构更容易迁移到微服务架构中呢?

这个问题的答案和其他优点表明我们应该使用哪种包结构。