鸿蒙 App 架构中的“领域拆分”

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、什么是“领域拆分”常见错误拆分二、领域拆分的核心思想正确结构三、为什么鸿蒙更需要领域拆分1、跨设备带来的复杂度2、任务驱动架构3、AI 接入四、如何拆分领域第一步识别领域第二步为领域建立目录第三步收拢代码第四步定义领域边界五、领域内部结构设计示例代码六、领域之间如何通信七、结合分布式架构八、结合 AI / Agent九、常见错误1、只是换目录不换思维2、领域过大3、领域过细十、本质总结结语引言很多鸿蒙项目做到中后期都会出现一种熟悉的状态页面越来越大 逻辑越来越乱 改一个功能影响一大片你可能已经做了这些优化拆组件抽 Service做状态管理但问题依然存在这时候你需要意识到一件事问题不在“代码写法”而在“架构划分方式”。更具体一点你没有做“领域拆分”。一、什么是“领域拆分”一句话解释按照“业务语义”而不是“技术层级”来组织代码。常见错误拆分pages/ services/ utils/ models/看起来很清晰但实际问题是业务被打散了例如一个“订单功能”代码可能分布在pages/order/ services/orderService.ts models/order.ts utils/format.ts结果一个功能被拆成了四五个地方二、领域拆分的核心思想领域拆分的目标是让“一个业务 一个独立模块”正确结构domains/ ├─ order/ │ ├─ OrderService.ts │ ├─ OrderModel.ts │ ├─ OrderRepository.ts │ ├─ OrderTask.ts │ └─ OrderPage.ets所有“订单相关”的代码都在一个地方三、为什么鸿蒙更需要领域拆分在传统 App 中问题还没那么严重。但在鸿蒙环境下多设备 分布式 任务驱动 AI 接入这些都会放大问题。1、跨设备带来的复杂度订单流程可能是手机选商品 ↓ 平板确认订单 ↓ 手表提醒如果没有领域拆分逻辑会散落在多个模块中2、任务驱动架构鸿蒙越来越强调Task / Agent例如classOrderTask{asynccreateOrder(itemId:string){returnawaitorderService.create(itemId)}}Task 必须依赖“完整领域能力”3、AI 接入AI 调用的是能力领域而不是页面例如awaitagent.run(帮我查订单)必须有OrderDomain四、如何拆分领域第一步识别领域问自己用户能做哪些事例如用户订单商品搜索支付每一个都是一个领域第二步为领域建立目录domains/ ├─ user/ ├─ order/ ├─ product/第三步收拢代码把原来分散的代码全部搬进对应领域例如// 原来在 services/orderService.ts// 现在domains/order/OrderService.ts第四步定义领域边界例如 OrderexportclassOrderService{create()cancel()list()}外部只能通过这些接口访问五、领域内部结构设计推荐一个实用结构order/ ├─ service/ │ └─ OrderService.ts ├─ model/ │ └─ Order.ts ├─ repository/ │ └─ OrderRepository.ts ├─ task/ │ └─ OrderTask.ts ├─ ui/ │ └─ OrderPage.ets示例代码ServiceexportclassOrderService{asynccreate(itemId:string){returnawaitorderRepo.save({itemId})}}RepositoryexportclassOrderRepository{asyncsave(order:any){returnawaitkvStore.put(order,order)}}TaskexportclassOrderTask{asyncrun(params){returnawaitorderService.create(params.itemId)}}形成闭环UI → Task → Service → Repository六、领域之间如何通信原则领域之间只能通过接口通信例如orderService.create()→ 调用 productService.getPrice()不要直接访问对方内部数据 错误七、结合分布式架构领域拆分后分布式会变得非常自然。例如classOrderRepository{asyncsave(order){awaitdistributedStore.put(order,order)}}所有设备共享同一领域数据八、结合 AI / Agent领域就是AI 的工具集例如agent.register(order.create,orderTask.run)AI 调用的是领域能力九、常见错误1、只是换目录不换思维代码还是耦合2、领域过大User Order Payment 写在一起 错误3、领域过细一个小功能一个领域 错误建议按业务能力拆分十、本质总结如果用一句话总结领域拆分是把“业务本身”变成架构单位。对比维度传统结构领域拆分拆分方式技术业务模块边界模糊清晰可维护性低高AI 支持弱强结语很多鸿蒙项目做着做着就乱了本质原因只有一个架构没有围绕“业务”来设计。当你完成领域拆分之后你会明显感受到代码更好找逻辑更清晰功能更容易扩展更重要的是分布式 AI 多设备这些能力会变得“自然可接入”。