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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人第一次做鸿蒙 App 时，项目结构通常是这样的：

pages/
components/
utils/
services/

刚开始：

页面不多
功能不复杂
开发效率很高

但随着业务增长，很快就会出现一种熟悉的情况：

登录功能依赖订单模块
订单模块依赖支付模块
支付模块又依赖用户模块

最后：

所有模块互相引用

出现：

改一个功能
全项目一起编译

甚至：

删代码不敢删
改逻辑不敢改

很多团队最后会发现：

真正让项目失控的，不是代码量，而是模块边界消失了。

所以对于中大型鸿蒙项目来说：

模块化不是优化，而是架构基础。

一、为什么鸿蒙 App 更需要模块化

传统移动应用：

单设备
单入口
单运行时

而鸿蒙天然具备：

• 手机
• 平板
• PC
• TV
• 穿戴设备
• 分布式协同

同时还有：

AI
Task
Store
分布式状态

项目复杂度远高于传统 App。因此：

功能增长
↓
模块增长
↓
依赖增长
↓
复杂度爆炸

如果没有模块化：

项目一定越来越难维护

二、模块化到底在解决什么问题

很多人认为：

模块化就是拆目录。

其实不是，真正解决的是：

边界问题。

例如，错误结构：

PageA
 ↓
PageB
 ↓
PageC
 ↓
PageD

形成：

网状依赖

最终：

谁依赖谁已经说不清

正确结构：

User
Order
Payment
Message

彼此独立：

模块内部高内聚
模块之间低耦合

三、最常见的错误拆分

很多项目喜欢按技术层拆：

pages/
services/
repositories/
models/

看起来很整齐，实际上：

一个订单功能
代码分散到十几个目录

例如：

OrderPage
↓
pages/

OrderService
↓
services/

OrderRepository
↓
repositories/

开发一个订单功能：

来回切目录

非常痛苦。

四、推荐的领域模块化

鸿蒙项目更推荐：

按业务领域拆分。

例如电商项目：

user/
order/
product/
payment/
message/

每个领域独立存在。

订单模块：

order/
 ├── ui/
 ├── store/
 ├── task/
 ├── system/
 ├── repository/
 └── model/

用户模块：

user/
 ├── ui/
 ├── store/
 ├── task/
 ├── system/
 ├── repository/
 └── model/

这样：

订单代码只在订单目录
用户代码只在用户目录

查找成本极低。

五、一个电商 App 的模块化设计

假设：

商城项目

主要能力：

• 登录
• 商品
• 购物车
• 订单
• 支付
• 消息

推荐结构：

src
├── app
├── common
├── user
├── product
├── cart
├── order
├── payment
└── message

公共能力：

common/

负责：

网络层
日志
工具库
配置
基础组件

例如：

HttpClient
Logger
Storage

六、模块内部如何设计

以订单模块为例，目录：

order/
 ├── ui
 ├── store
 ├── task
 ├── system
 ├── repository
 └── model

UI 负责：

页面展示

例如：

OrderPage.ets

Store 负责：

订单状态

例如：

export class OrderStore {

  orders: Order[] = []

}

Task 负责：

任务编排

例如：

CreateOrderTask.ts

System 负责：

业务处理

例如：

OrderSystem.ts

Repository 负责：

数据访问

例如：

OrderRepository.ts

七、模块之间如何通信

很多项目最容易出问题：

模块直接调用模块

例如：

orderStore.userStore

或者：

paymentStore.orderStore

这样会形成：

循环依赖

正确方式，通过接口通信。例如：

interface IUserService {

  getUser(): Promise<User>

}

订单模块：

constructor(
  private userService: IUserService
) {}

依赖：

能力

而不是：

具体实现

八、Store 不要跨模块共享

错误写法：

productStore.orders

或者：

userStore.cart

这样：

模块边界消失

正确做法，模块只管理自己的状态。例如，订单模块：

orderStore.orders

商品模块：

productStore.products

用户模块：

userStore.user

互不持有。

九、结合 Task 架构

未来鸿蒙 App 会越来越偏向：

Task 驱动

而不是：

页面驱动

例如，创建订单：

await taskCenter.run(
  "create_order"
)

任务内部：

class CreateOrderTask {

  async run() {

    const order =
      await orderSystem.create()

    orderStore.set(order)

  }

}

架构：

UI
 ↓
Task
 ↓
System
 ↓
Repository
 ↓
Store

模块边界非常清晰。

十、结合 AI Native 架构

未来很多鸿蒙 App：

Agent

会成为新入口，例如：

await agent.run(
  "帮我购买这本书"
)

此时，AI 不应该直接操作页面。正确方式：

Agent
 ↓
Task
 ↓
Module

例如：

await taskCenter.run(
  "create_order"
)

订单模块执行、支付模块执行、消息模块执行。

每个模块：

独立自治

十一、模块化与分布式能力

鸿蒙最大的特点：

分布式

例如，手机：

创建订单

PC：

查看订单

TV：

展示订单

如果没有模块化：

状态同步非常混乱

正确结构：

Distributed State
        ↓
Order Module
        ↓
Order Store
        ↓
UI

模块天然成为：

同步边界

十二、一个推荐的最终架构

对于中大型鸿蒙 App，推荐结构：

App
 │
 ├── Common
 │
 ├── User
 │    ├── UI
 │    ├── Store
 │    ├── Task
 │    ├── System
 │    └── Repository
 │
 ├── Order
 │    ├── UI
 │    ├── Store
 │    ├── Task
 │    ├── System
 │    └── Repository
 │
 ├── Payment
 │
 ├── Message
 │
 └── Product

核心原则：

按领域拆
而不是按技术拆

十三、总结

如果用一句话总结模块化：

模块化的本质，不是拆代码，而是建立边界。

优秀鸿蒙项目都有一个共同点：

状态有边界
模块有边界
任务有边界
设备有边界

这样即使项目做到：

几十万行代码

依然能够：

快速迭代
快速定位
快速扩展

很多鸿蒙项目后期越来越难维护，并不是因为：

• 页面太多
• 功能太复杂
• 分布式太难

真正的问题只有一个：

所有代码最终长成了一个“大模块”。

记住一句话：

没有模块边界的系统，
最终一定会变成一个巨大的耦合体。

当你真正建立：

• 领域模块
• Store隔离
• Task中心化
• 无状态System
• 分布式边界

你会明显感受到：

项目开始拥有“可演进能力”

而这也是鸿蒙 App 从 Demo 走向大型商业项目的重要分水岭。