flutter-architecture

Flutter 架构

选择复杂度最低的架构，同时确保职责清晰、状态可测试且依赖可替换。

迁移前先保留现状

检查现有的功能结构、状态机制、依赖注入、数据源、测试和团队约定。即使现有架构与偏好的示例不同，也要在连贯的架构基础上扩展。只有针对具体问题才提议迁移，并以增量方式进行。

基本边界

• 视图负责渲染状态并转发用户意图；将数据访问和业务规则放在组件之外。
• 表现层逻辑负责 UI 状态和命令。
• 仓库是领域数据的事实来源，并协调服务或缓存。
• 服务封装 HTTP、存储和平台插件等外部系统。
• 只有在逻辑可复用、较复杂或会让表现层状态变得臃肿时，才添加用例或领域服务。
• 只有在替换或测试确有需要时，才通过显式接口让依赖指向内层。

Flutter 团队的 MVVM 指南是新建可扩展应用时一个实用的默认选项，并不要求替换 Riverpod、Bloc、Redux 或已有的功能优先设计。

组织方式

优先按面向用户的功能划分边界。将真正共享的基础设施放在精简的核心区域。避免建立堆积无关模型、组件和辅助工具的全局文件夹。

新项目选型或渐进式迁移时，加载 greenfield and evolution。模块跨功能泄漏或职责归属不清时，加载 feature boundaries and dependency rules。

验证

展示一个功能的依赖路径；在可行的情况下，无需渲染组件即可测试表现层逻辑；并确认没有引入循环依赖或绕过 UI 层直连基础设施的捷径。

来源

• Flutter 架构指南
• 常见架构概念