[译]按功能（特性）分包
一种流行的方法是通过技术层面对项目进行分包。但是这种方法有一些缺点。相反，我们可以按功能分包并创建独立自治的程序包。结果是一个易于理解且不易出错的代码库。
整体分析
按照技术分包造成的缺点：
-
对属于某个功能的所有类的概述不佳。
-
通用代码、重用代码和复杂代码趋向于难以理解，并且由于难以把握变更的影响，因此变更很容易破坏其他功能用例。
按功能分包从而创建包含功能所需的所有类的程序包。好处是：
- 更好的可发现性和概览
- 独立且自治
- 更简单的代码
- 可测试性
- 便于团队协作开发
按照技术分层分包
项目结构的一种非常流行的方法是逐层分包。这将为每个技术组所属类提供一个软件包。
⚠️：按层分包从技术角度对所有类进行分组
让我们将调用层次结构添加到图片中，以“清楚地”了解哪个类取决于其他哪个类。
⚠️：调用层次结构遍及整个项目，涉及许多包
那么，按层分包的缺点是什么？
-
功能概述不佳。通常，当我们在项目中处理代码时，我们首先会想到要更改的特定领域或功能。因此，我们会从领域的角度出发。不幸的是，按技术分层分包迫使我们从一种软件包过渡到另一种软件包，才能掌握功能的概况。
-
通用，重用和复杂代码的趋势。通常，这种方法导致中心类包含每个功能用例的所有方法。随着时间的流逝，这些方法越来越抽象化（带有额外的参数和泛型）来满足更多用例。上图中仅一个示例是ProductDAO，其中放置了ProductController和ExportController的方法。结果是：
-
当添加更多方法时，类将变得更大。因此，仅凭代码量，就很难理解它。
-
更改通用重用代码很危险。尽管您只想处理一个用例，但您可以轻松地打破所有用例。
-
由于以下两个原因，难以理解抽象方法和通用方法：首先，要通用，通常需要其他技术构造（例如，switch，参数，泛型），这使得查看与当前用例相关的业务逻辑更加困难。其次，认知需求更高，因为您必须了解所有其他用例，以确保您不会破坏它们。
-
桑迪·梅斯（Sandi Metz）指出：
“我觉得我必须了解所有内容才能提供帮助。”桑迪·梅斯（Sandi Metz）。请参阅我的帖子，了解我们的编码智慧墙。
⚠️：我们达到了DRY，但违反了KISS。
按功能（特性）分包
让我们将这些类重新排列成独立的功能包。
👆用户管理功能包
新的包userManagement包含属于此功能的所有类：控制器，DAO，DTO和实体。
👆产品管理功能包
新软件包productManagement包含相同的类类型，以及StockServiceClient和相应的StockDTO。这个事实清楚地表明：库存服务仅由产品管理人员使用。
userManagement和productManagement使用不同的域实体和表。将它们分成不同的包很简单。但是，当一个功能需要与另一个功能相似或甚至相同的域实体时，会发生什么？
👆产品出口的功能包
现在，它变得越来越有趣。exportProduct包也处理产品实体，但具有不同的功能用例。
我们的目标是拥有独立自治的功能包。因此，exportProduct应该具有自己的DAO，DTO类和实体类，即使它们看起来与productManagement中的类相似。抵制重用productManagement中的类的冲动。
- 我们可以使用针对出口用例量身定制的结构（DTO，实体）。它们仅包含相关字段，并且可以基于具有相关列的良好投影的查询来创建实体-别无其他。
- 专用的ExportProductDAO包含特定于出口功能的查询和预测。
我们可能不得不再次编写更多代码，但最终会遇到非常有利的情况：
- productManagement中的更改永远不会破坏exportProduct代码，反之亦然。它们可以独立发展。
- 更改代码时，我们仅需牢记当前功能。
- 代码本身将变得更加简单易懂，因为它不是通用的，并且不必在两个用例中都可以使用。
上面的功能包很棒，但实际上，我们将始终需要一个通用的包。
👆通用软件包包含技术配置和可重复使用的代码
它包含技术配置类（例如用于DI，Spring，对象映射，http客户端，数据库连接，连接池，日志记录，线程池）
它包含可重用的有用代码片段。但是要非常小心代码的过早抽象。我总是先把代码放到尽可能接近它的用法的地方，也就是特性包，甚至是使用类。仅当片段确实有更多用途（⚠️：而不是我认为将来可能会使用）时，才将其移动到通用包中。三定律提供了很好的指导。
在通用包中找到所有实体可能是有意义的。我们还对某些项目执行了此操作，其中许多功能包一次又一次地使用相同的实体。一些开发人员还希望将所有实体放在中心位置，以便能够整体查看数据库架构的映射。目前，我并不是教条，因为实体的两个位置都可以合理。不过，一开始我总是尽可能多地将代码转移到功能包中，并依赖于定制的特定于用例的实体和投影。
大图景
最终，我们的大图看起来像这样：
👆按功能分包的大图
好处
让我们简要总结一下好处：
- 从域的角度来看，更好的可发现性和概述。属于业务功能的大多数代码位于一起。这很关键，因为我们通常会在考虑某个业务需求的情况下访问代码库。
- 独立的和自治的。功能所需的大多数代码都位于一个程序包中。因此，我们避免依赖其他功能包。结果是：在开发功能时，我们不太可能破坏其他功能。需要较少的认知能力来估计变化的影响。通常，我们只需要记住当前的软件包即可。
- 更简单的代码。由于我们避免使用通用和抽象的代码，因此代码变得更加简单，因为它只需要处理一个用例。因此，更容易理解和改进代码。
- 可测试性。通常，与试图满足所有用例的技术包中的“上帝类”相比，功能包中的类具有较少的依赖关系。因此，由于我们可以创建更少的测试依赖，因此测试变得更加容易。
缺点
- 我们必须编写更多代码。
- 我们可能会多次编写类似的代码。
- 决定何时才能更好地将代码移至通用软件包并重用它是很难的。有疑问时，“三定律”很有用。我想强调指出，重用仍然是允许且有用的。
- 找出功能包的适当范围和大小也很棘手。有关详细信息，请参阅问题部分。
但是，我认为优点大于缺点。
背后的原理
拟议的按功能分包方法遵循的原则非常贴切：
KISS > DRY
再次，我想引用桑迪·梅斯（Sandi Metz）
“我觉得我必须了解所有内容才能提供帮助。”桑迪·梅斯（Sandi Metz）。请参阅我的帖子，了解我们的编码智慧墙。
按功能包装的方法
我们的团队记录了其遵循的编码准则和原则。关于按功能分包的部分如下所示：
我们基于功能分包。每个功能包均包含提供该功能所需的大多数代码。每个功能包都应独立且自治。
├── feature1
│ ├── Feature1Controller
│ ├── Feature1DAO
│ ├── Feature1Client
│ ├── Feature1DTOs.kt
│ ├── Feature1Entities.kt
│ └── Feature1Configuration
├── feature2
├── feature3
└── common
- 这种方法影响所有层。例如，每个程序包都有自己的DAO和客户端。不应有庞大的DAO类神。
- 一个程序包应该与其他程序包只有几个关系。该功能所需的所有逻辑事物都应放在程序包内。
- 经验法则：如果要删除功能，则只需删除相应的程序包。
- 尽管如此，也可以在通用软件包中重复使用东西，但它只应包含多次使用的代码（请参阅三定律）。它不应该包含业务逻辑。但是技术上有用是可以的。
- 如果存在特定于特性的Spring Bean，我们将把它们的配置放在特性包中。
问题
功能包中的结构如何？
这取决于项目和功能包的大小。
对于中小型项目，我喜欢避免定义可能会增加更多仪式而非价值的规则（例如，要求定义某些接口和子包）。只要您构建独立的、自治的、从您的特定业务领域派生的包，您就在正确的轨道上。
如果要处理更大的代码库，则可能需要定义有关子包结构和方式的更多规则，则允许一个功能包访问另一个功能包。“模块”或“组件”而不是“功能包”的概念可能更有帮助。例如，Tom Hombergs建议在每个组件包中添加api和内部包，这些组件包定义组件的哪些部分允许其他组件使用。有关详细信息，请参阅他的文章“使用Spring Boot和ArchUnit清理架构边界”。
我最终会一次又一次写相同的代码吗？
是的，会有一些重复，但是根据我的经验，您可能不会相信那么多100％相同的代码。由于相似的代码涵盖了不同的用例，因此通常是不同的。例如，两种方法可以按产品名称查询产品，但是它们在计划的字段，排序和其他条件方面有所不同。因此，最好将方法分开放在不同的程序包中。
而且，复制本身并不是邪恶的。在开始将代码提取到通用重用方法之前，我喜欢应用三定律。
最后，我想强调指出，仍然允许集中使用可重用的代码，有时甚至是合理的，但是这些情况不再那么常见了。
Kotlin可以支持这种方法吗？
分包方法与语言无关。但是Kotlin使其易于遵循：
使用数据类，编写量身定制的特定于功能的结构（如DTO或实体）仅需几行，而无需样板。
Kotlin允许将多个类放在一个文件中。因此，我们可以使一个包含所有数据类定义的DTOs.kt或Entities.kt文件成为一个单独的DTOs.kt或Entities.kt文件，而不是有一个子包DTO或包含每个POJO类的许多Java文件的实体。
本文翻译自：https://phauer.com/2020/package-by-feature/
关注笔者公众号，推送各类原创/优质技术文章 ⬇️
