Flutter中的功能模块化：如何结合Clean Architecture与领域驱动设计实现自包含、可扩展的功能
内容提要
本文介绍Flutter应用的功能模块化架构，旨在解决团队扩大后代码库混乱的问题。它结合Clean Architecture的分层规则和领域驱动设计的建模概念，按功能而非技术层组织代码，每个功能包含独立的领域、应用、基础设施和展示层。通过实体、值对象和用例封装业务规则，实现可独立测试和扩展，支持从单人开发扩展到五十人团队。
延伸解读
从分层到功能模块化的转变
文章指出，传统的按技术层组织代码（如domain、application、infrastructure、presentation）在团队扩大后会变得难以维护：修改一个功能需要跨多个文件夹，新成员难以理解，测试困难。功能模块化将每个功能作为垂直切片，包含自己的领域、应用、基础设施和展示层，从而解决这些问题。这种组织方式让每个功能独立、可测试，并支持团队扩展。
领域层是业务规则的核心
在功能模块化中，业务规则被严格封装在领域层。值对象（如EmployeeId、Money）在构造时验证数据有效性，实体（如Employee、Payment）通过方法（如clockIn、complete）强制状态转换规则，领域服务处理跨实体的逻辑。这种设计确保业务规则无法被绕过，因为只有通过领域对象才能修改状态。
跨功能通信的边界
功能模块化要求功能之间不直接导入内部代码，而是通过共享核心（shared/core）中的接口或事件总线进行通信。例如，支付功能通过定义在共享核心的EmployeeService接口来获取员工信息，而不是直接依赖员工功能。这保持了功能的独立性，同时允许必要的协作。
从单仓库到多包扩展
文章提到，当团队规模达到30人以上，功能可以拆分为独立的Dart包（如packages/employee），每个包有自己的pubspec.yaml和测试，可独立版本化。到50人时，团队可以拥有整个功能包，包之间的接口成为团队间的API边界。这种结构从单一代码库平滑过渡到多包仓库，无需改变核心概念。
Q&A
什么是Flutter中的功能模块化？
功能模块化是一种组织Flutter应用代码的策略，它围绕功能而非技术层来组织代码。每个功能都是一个垂直切片，包含自己的领域模型、业务规则、数据访问和UI，使其自包含、可独立测试和扩展。它结合了Clean Architecture的分层规则和领域驱动设计的建模概念。
为什么传统的按层组织代码在大型Flutter项目中会导致问题？
按层组织代码将代码按技术角色分组，如domain、application、infrastructure和presentation。在小型项目中可行，但随着项目增长，修改一个功能需要跨多个文件夹，理解功能需要从分散的代码中拼凑，测试困难，新工程师上手慢，最终导致代码库混乱。
在功能模块化中，Clean Architecture和领域驱动设计各自贡献了什么？
Clean Architecture提供了分层规则，确保内层不依赖外层，领域层是纯Dart，不依赖Flutter或外部库。领域驱动设计提供了建模词汇，如实体、值对象、领域服务和仓储接口，用于在领域层中捕获业务复杂性。两者结合，在功能级别应用这些原则。
在功能模块化中，实体、值对象和DTO有什么区别？
实体是具有身份和状态变化规则的对象，如Employee实体有ID和打卡规则。值对象是封装单个数据并强制其有效性的不可变对象，如EmployeeId和Money，在构造时验证数据。DTO是数据传输对象，用于从外部源（如API）传输原始数据，没有业务规则，通常位于基础设施层，并负责转换为领域对象。
在功能模块化中，业务规则应该放在哪里？
业务规则必须放在领域层。值对象强制原子规则，实体强制状态规则，领域服务处理跨实体的规则。应用层调用领域，基础设施层实现接口，展示层只响应结果，不定义或修改业务规则。
功能模块化如何处理跨功能通信？
跨功能通信遵循规则：功能之间不直接导入内部层；共享领域概念放在shared/core；通过定义接口进行通信，如EmployeeService接口；使用共享事件总线发布和订阅领域事件，如PaymentCompleted事件。
功能模块化如何支持团队从10人扩展到50人？
在10人时，功能自包含减少合并冲突；在30人时，功能可以变成独立的Dart包，有自己的pubspec.yaml和测试；在50人时，团队可以拥有整个功能包，通过shared/core中的接口定义API边界，独立发布和更新。
在功能模块化中，异常处理是如何工作的？
领域层抛出DomainException，应用层捕获并返回Result失败，展示层将Result转换为AsyncError状态，最终由widget渲染错误。异常不会导致应用崩溃，而是被安全地转换为UI状态。
