遵循Clean Architecture的Flutter跨应用可复用功能模块化咨询

问题1答复 #

你提出的以「最高公共稳定层」作为模块边界的方案完全可行，是Clean Architecture下做可复用模块的标准落地实践之一。
行业内确定模块边界的核心原则可以总结为2条：

• 按「变化频率」拆分：把长期稳定、不需要随业务场景调整的逻辑全部收拢到core模块，把会随对接服务、业务定制变化的逻辑拆为独立的实现模块或者留在宿主项目中。你当前把通用校验逻辑、认证状态管理、domain层契约放到core_auth_kit，把不同后端的对接逻辑拆成独立实现包的做法，完全符合这个原则。
• 按「依赖方向」约束：所有实现层模块只能依赖core模块暴露的抽象接口，不能反向依赖宿主项目的业务逻辑，core模块也不能依赖任何具体的实现层（比如不能在core里引入firebase的sdk），保证core模块的通用性不受具体实现限制。
  如果要优化的话，可以在core模块里补充一些无样式的通用UI辅助能力，比如表单校验mixin、通用状态回调接口，进一步减少业务侧的重复代码，同时不侵入业务侧的自定义UI逻辑。

问题2答复 #

判断抽成module还是template的核心标准是：你是否需要对这部分复用逻辑做统一的版本迭代维护。

• 如果该功能的核心逻辑需要后续统一升级（比如你后续要给认证功能加手机号登录、第三方登录的通用能力，希望所有用到的项目只需要升级包版本就能用上新能力），同时修改点集中在实现层、核心逻辑稳定，就做成module。
• 如果该功能每个项目的定制化改造量远大于可复用的代码量，或者你不需要对这部分代码做后续的统一维护，后续修改都由各个项目自己负责，就做成template。

你举的认证场景非常适合做成module：核心的认证逻辑、状态管理、规则校验都是稳定的，可复用比例极高，后续迭代也只需要更新core包即可，远优于每次用template拷贝代码再修改的效率。

内容的提问来源于stack exchange，提问作者Ivan Doronin