我们最近遇到了这个问题，因为我们过渡到多模块项目以进行重用，构建时间优化(不变的模块不会重新编译)等.核心目标是使您的app模块尽可能小，因为每次都会重新编译.

We recently encountered this problem, as we transitioned to a multi-module project for reuse, build time optimisation (unchanged modules aren't recompiled), etc. Your core goal is to make your app module as small as possible, as it will be recompiled every time.

我们使用了一些通用原则，这些原则可能会对您有所帮助:

We used a few general principles, which may help you:

• 常见的base-ui模块包含主要的strings.xml，styles.xml等.
• 其他前端模块(profile，dashboard等)实现此base-ui模块.
• 将在 all 所有面向用户的模块中使用的库作为api而不是implementation包含在base-ui中.
• 仅在 some 模块中使用的库仅作为依赖关系添加在这些模块中.
• 该项目也大量使用了数据同步等功能，因此也有遵循相同逻辑的base-data，dashboard-data等模块.
• dashboard功能模块取决于dashboard-data.
• app模块仅取决于功能模块，dashboard，profile等.

• A common base-ui module contains the primary strings.xml, styles.xml etc.
• Other front-end modules (profile, dashboard, etc) implement this base-ui module.
• Libraries that will be used in all user-facing modules are included in base-ui, as an api instead of implementation.
• Libraries that are only used in some modules are added as dependencies only in those modules.
• The project makes extensive use of data syncing etc too, so there are also base-data, dashboard-data etc modules, following the same logic.
• The dashboard feature module depends on dashboard-data.
• The app module depends only on feature modules, dashboard, profile, etc.

我强烈建议您事先勾勒出您的模块依赖流程，最后我们得到了大约15个左右的模块，所有模块都经过严格组织.在您的情况下，您提到它已经是一个很大的应用程序，因此我想app和domain一样都需要从其中提取功能模块.记住，小的模块=更少的代码可以重新编译！

I strongly suggest sketching out your module dependency flow beforehand, we ended up with ~15 or so modules, all strictly organised. In your case, you mentioned it's already quite a large app, so I imagine app needs feature modules pulled out of it, as does domain. Remember, small modules = less code to be recompiled!

在确保在所有子模块上使用相同版本的应用程序(buildType，flavors)时，我们遇到了一些问题.本质上，所有子模块都必须具有与app模块相同的flavor和buildType定义.

We encountered some issues with making sure the same version (buildType, flavors) of the app was used across all submodules. Essentially, all submodules have to have the same flavors and buildTypes defined as the app module.

另一方面，多模块开发确实使您思考依赖关系，并强制功能之间严格分离.您可能会遇到一些以前从未考虑过的意外问题.例如，显示应用程序版本突然变得复杂(免责声明:我的文章).

On the other side of the coin, multi module development does really make you think about dependencies, and enforces strict separation between features. You're likely to run into a few unexpected problems that you've never considered before. For example, something as simple as displaying the app's version suddenly complicates (disclaimer: my article).

本文还帮助我们决定了方法.您链接的文章似乎也是很好的参考资料，我希望它在我们过渡时就已经存在！

This article also helped us decide on our approach. The article you linked also seems to be an excellent resource, I wish it had existed when we'd transitioned!

在评论讨论之后，这是一个示例图(不幸的是，它很曲折，但足以说明该概念.请注意，将api和implementation进行区分是一个不错的下一步):

After comment discussion, here's an example diagram (with unfortunate untidiness, but enough to illustrate the concept. Note that distinguishing between api and implementation would be a good next step):