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

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- 一、什么是"领域拆分"
- - 常见错误拆分
- 二、领域拆分的核心思想
- - 正确结构
- 三、为什么鸿蒙更需要领域拆分
- - 1、跨设备带来的复杂度
  - 2、任务驱动架构
  - [3、AI 接入](#3、AI 接入)
- 四、如何拆分领域
- 五、领域内部结构设计
- - 示例代码
- 六、领域之间如何通信
- 七、结合分布式架构
- [八、结合 AI / Agent](#八、结合 AI / Agent)
- 九、常见错误
- 十、本质总结
- 结语

引言

很多鸿蒙项目做到中后期，都会出现一种熟悉的状态：

复制代码

页面越来越大
逻辑越来越乱
改一个功能影响一大片

你可能已经做了这些优化：

拆组件
抽 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

例如：

ts 复制代码

class OrderTask {

  async createOrder(itemId: string) {
    return await orderService.create(itemId)
  }

}

Task 必须依赖"完整领域能力"

3、AI 接入

AI 调用的是：

复制代码

能力（领域）

而不是：

复制代码

页面

例如：

ts 复制代码

await agent.run("帮我查订单")

必须有：

复制代码

OrderDomain

四、如何拆分领域

第一步：识别领域

问自己：

复制代码

用户能做哪些事？

例如：

用户
订单
商品
搜索
支付

每一个都是一个领域

第二步：为领域建立目录

复制代码

domains/
 ├─ user/
 ├─ order/
 ├─ product/

第三步：收拢代码

把原来分散的代码：全部搬进对应领域

例如：

ts 复制代码

// 原来在 services/
orderService.ts

// 现在
domains/order/OrderService.ts

第四步：定义领域边界

例如 Order：

ts 复制代码

export class OrderService {
  create()
  cancel()
  list()
}

外部只能通过这些接口访问

五、领域内部结构设计

推荐一个实用结构：

复制代码

order/
 ├─ service/
 │   └─ OrderService.ts
 ├─ model/
 │   └─ Order.ts
 ├─ repository/
 │   └─ OrderRepository.ts
 ├─ task/
 │   └─ OrderTask.ts
 ├─ ui/
 │   └─ OrderPage.ets

示例代码

Service

ts 复制代码

export class OrderService {

  async create(itemId: string) {
    return await orderRepo.save({ itemId })
  }

}

Repository

ts 复制代码

export class OrderRepository {

  async save(order: any) {
    return await kvStore.put("order", order)
  }

}

Task

ts 复制代码

export class OrderTask {

  async run(params) {
    return await orderService.create(params.itemId)
  }

}

形成闭环：

复制代码

UI → Task → Service → Repository

六、领域之间如何通信

原则：

领域之间只能通过接口通信

例如：

ts 复制代码

orderService.create() 
→ 调用 productService.getPrice()

不要：

ts 复制代码

直接访问对方内部数据 错误

七、结合分布式架构

领域拆分后，分布式会变得非常自然。

例如：

ts 复制代码

class OrderRepository {

  async save(order) {
    await distributedStore.put("order", order)
  }

}

所有设备共享：

复制代码

同一领域数据

八、结合 AI / Agent

领域就是：

复制代码

AI 的工具集

例如：

ts 复制代码

agent.register("order.create", orderTask.run)

AI 调用的是：

复制代码

领域能力

九、常见错误

1、只是换目录，不换思维

代码还是耦合

2、领域过大

复制代码

User + Order + Payment 写在一起 错误

3、领域过细

复制代码

一个小功能一个领域 错误

建议：

复制代码

按业务能力拆分

十、本质总结

如果用一句话总结：

领域拆分，是把"业务本身"变成架构单位。

对比：

维度	传统结构	领域拆分
拆分方式	技术	业务
模块边界	模糊	清晰
可维护性	低	高
AI 支持	弱	强

结语

很多鸿蒙项目做着做着就乱了，本质原因只有一个：

架构没有围绕"业务"来设计。

当你完成领域拆分之后，你会明显感受到：

代码更好找
逻辑更清晰
功能更容易扩展

更重要的是：

复制代码

分布式
AI
多设备

这些能力会变得"自然可接入"。