Android多模块功能架构的实现方法

Unsplash@chuklanov

为您的Android项目设计一个有效的架构至关重要，尤其是当你打算长期维护它的时候。你选择的策略会受到多种因素的影响，包括项目的规模、资源、目标以及技术堆栈。

采用多模块功能架构时，你可以从更佳的复用性、并行开发的优势和分散的关注点中受益。然而，重要的是要仔细考虑如何划分模块——是按功能、领域，还是符合项目特定需求的其他标准。

这篇文章讨论了构建多模块架构的有趣方式，这是最近在Dove Letter上，有人提出的话题。Dove Letter 是一个订阅平台，在这里你可以学习、讨论和分享关于 Android 和 Kotlin 的新想法。如果你感兴趣，可以看看 “通过 Dove Letter 学习 Kotlin 和 Android” 。

如何在多模块架构中结构化你的模块

这可能是你在开始配置项目时最先想到的想法之一。最近，有一个有趣的问题被提出来了。这个问题由一位订阅者在Dove Letter（一个GitHub上的项目）上提出。

该订阅者提出了以下四种不同的模块化方案，以供考虑。

模式一

在根目录下，创建一个名为 onboarding 的功能模块文件夹。在该文件夹下，创建两个 Android 库模块：一个用于 domain，另一个用于 presentation。

它的结构是这样的，主模块独立存在，其中的域层和展示层子模块也是独立的。

好处

这种方法按照功能来分离关注点，并且隔离开领域层和表现层，从而有助于实现干净的架构。它支持模块化，鼓励重用领域逻辑，并促进按功能及其领域/表现层独立测试。此外，它具有高度的可扩展性，非常适合大型复杂项目。因此，如果你的团队规模很大，每个团队都在处理不同的功能，并且每个方面都需要分开，这种模式可能是很好的选择。

不太好的地方

然而，它会增加项目中多个模块的复杂性。管理这些模块间的依赖关系也可能会非常困难，可能导致需要小心处理的互相依赖性。特别需要注意的是，在这种架构中潜在的循环依赖性。如果出现依赖循环，可能会让项目变得难以管理。此外，这种结构既具有挑战性，又需要耗费大量资源来维护，听起来确实成本不菲 💸

模式二

在根目录创建一个features Android库。然后，在features模块下，将每个单独的功能组件作为单独的Android库添加。

这种模式是将所有内容整合到一个功能模块里；听起来很简单，是不是？

优点

这非常简单。更易于管理和复杂度更低。如果你认为你将构建的只是一个小项目或不会涉及超过1到2名开发者的项目，这种模式可能是个好选择。有时候，简单就是最好的！

不足之处

此模式提供了简单性并易于管理。虽然它允许一定程度的模块化，但这种模块化是有限的，随着项目规模的增大，其可扩展性有限。此外，领域层和表示层没有分离，这可能导致随着项目变得越来越复杂，保持清晰架构的挑战。

第3种模式

从一个名为 onboarding 的功能模块（Android 库插件）开始。在这个模块内，创建两个额外的 Android 库模块插件：一个用于 domain 部分，另一个用于 presentation 部分。

听起来这个功能模块比模式1更嵌套，我的回答也和模式1一样。

模式四

在根目录下创建一个feature文件夹，然后为每个功能创建一个独立的Android库模块。比如说，在feature文件夹中有一个auth库模块，就在auth库模块下创建DI、Domain和Presentation的子文件夹。

这种模式很适合大多数项目，特别是当您的团队是中等规模的团队（大约10到30名工程师），且不需要为50到100名工程师的大型团队提供高可扩展性时。或者，你也可以选择在根级别创建独立的领域和表现模块，这样可以在你的代码库中明确划分职责。这种方法与流行的“干净架构”原则非常契合，有助于保持代码库的结构清晰且易于维护。

优点如下

该模式通过将简洁性与模块化相结合来简化结构，每个特性都被封装在独立的模块中，内部相互独立。它易于管理且导航清晰，非常适合中等规模的项目开发。

不足之处

然而，这种模式在隔离上存在局限性，因为领域层和表示层并没有物理上分离成独立的模块，可能会影响灵活性。此外，与使用完全独立模块划分每一层的架构相比，它的扩展性较差。因此，将领域层和表示层分离成独立模块会是一个更好的选择。

总结

• 模式1和模式3最适合大型复杂项目，需要清晰的模块划分和高可扩展性。
• 模式4适合中型项目，其重点是简单性，但仍希望保持一定的模块化。
• 模式2最适合小型项目，在这些项目中，简洁性和速度比严格遵循架构原则更为重要。如果你在一个团队中快速构建项目以验证你的商业MVP的可行性验证，可以选择这个模式，而不是花费大量时间去构建那些没必要的模块。

最后的总结

我们已经探索了四种不同的模块化模式，用于配置您的多模块架构项目的方式，并分析了每种方法的优缺点的情况。正如您可能已经发现的那样，确定项目架构的最佳方式在很大程度上取决于其复杂性和可扩展性需求——没有一种一劳永逸的解决方案。每个项目都有自己独特的特性与需求，理解这些需求对于选择最合适的架构模式来说非常重要。

如果你对该文章有任何疑问或反馈，可以在 Twitter @github_skydoves 或 GitHub GitHub 上联系作者。如果你想了解最新的文章、参考资料、包含代码示例的最佳实践提示和关于整个 Android/Kotlin 生态系统的信息，可以查看“通过‘鸽子信’学习 Kotlin 和 Android”。

编程愉快！

— Jae Woon （链接到 skydoves 的 GitHub 页面）