flutter - 在 Flutter 应用程序中模块化可重用功能的最佳方式是什么？

Question

TLDR：当遵循干净的架构时，何时应该通过模块与模板在不同的应用程序中重用可重用的功能，以及如何决定模块的接口？

背景

我目前正在为可以在多个 Flutter 应用程序中重用的通用功能编写一些包（供自由职业时个人使用），并且想知道什么是组织它们的好方法。对于我的应用程序，我遵循干净的架构指南，按功能拆分应用程序，每个功能由数据、域和表示层组成：

|--> lib/
      |
      |--> feature_a/
      |       |
      |       |--> data/
      |       |      |
      |       |      |--> data_sources/
      |       |      |
      |       |      |--> repository_implementations/
      |       |      |
      |       |--> domain/
      |       |      |
      |       |      |--> repository_contracts/
      |       |      |
      |       |      |--> entities/
      |       |      |
      |       |      |--> use_cases/
      |       |      |
      |       |--> presentation/
      |       |      |
      |       |      |--> blocs/
      |       |      |
      |       |      |--> screens/
      |       |      |
      |       |      |--> widgets/
      |       |      |
      |--> feature_b
      |       |
      |       |--> ...

例子

如果我们以用户身份验证功能为例，我知道：

• 整个域层以及 bloc在大多数应用程序（电子邮件和密码验证、身份验证/登录 bloc 等）中都是相同的
• 数据层将根据后端/数据库而变化（不同的提供者 = 不同的调用）
• 屏幕/小部件会随着不同的用户界面而变化（不同的应用程序会有不同的登录和入职页面）

当前方法

我的想法是编写类似于单个后端无关的“core_auth_kit”包，其中包含域和块，以及我可能使用的每个后端服务的一个包，例如“firebase_auth_kit”、“mongodb_auth_kit”等。每个后端特定包将使用“core_auth_kit”作为向外的接口。

这是我打算如何使用它。如果我正在编写一个简单的 Firebase Flutter 应用程序，我将简单地导入“firebase_auth_kit”包，并在 MultiBlocProvider 内的应用程序根目录处实例化其 auth_bloc，如果状态为“未验证”则显示登录页面和主页如果它是“认证的”。

问题

1. 决定模块边界的标准做法是什么？即这种使用“最高公共层”（身份验证示例中的块）的方法是要走的路吗？
2. 何时应该将可重用的功能提取为模板与模块（我的示例是模块的良好候选者，还是应该改为模板）？

标签： flutterauthenticationdesign-patternsinterfacearchitecture