引言

在HarmonyOS应用开发过程中，随着项目规模的增长，代码的组织结构显得尤为重要。
DevEco Studio创建出的默认工程仅包含一个entry类型的模块，如果直接使用平级目录进行模块管理，工程逻辑结构较混乱且模块间的一栏关系不够清晰，不利于多人开发及维护。

本文将介绍一种经过实践验证的三层工程架构方案，帮助开发者构建清晰、可维护、可扩展的HarmonyOS应用工程结构。

三层工程架构设计

1. commons（公共能力层）

用于存放公共基础能力集合（如工具库、公共配置等）。commons层可编译成一个或多个HAR包或HSP包，只可以被products和features依赖，不可以反向依赖。

定位：公共基础能力集合，是整个应用的基石

职责：

• 提供工具类和工具方法（网络请求、存储、日志等）
• 定义公共配置和常量
• 封装基础UI组件
• 提供通用业务逻辑封装

编译形式：HAR包或HSP包

依赖规则：

• 只可以被products和features层依赖
• 不可以反向依赖其他层
• 不可以依赖products层

目录示例：

2. features（基础特性层）

用于存放基础特性集合（如应用中相对独立的各个功能的UI及业务逻辑实现等）。各个feature高内聚、低耦合、可定制，供产品灵活部署。不需要单独部署的feature通常编译为HAR包或HSP包，供products或其它feature使用。需要单独部署的feature通常编译为Feature类型的HAP包，和products下Entry类型的HAP包进行组合部署。features层可以横向调用及依赖common层，同时可以被products层不同设备形态的HAP所依赖，但是不能反向依赖products层。

定位：基础特性集合，包含应用中相对独立的功能模块

职责：

• 实现具体的业务功能模块
• 提供高内聚、低耦合的特性实现
• 支持可定制和灵活部署

编译形式：

• 不需要单独部署的feature：HAR包或HSP包
• 需要单独部署的feature：Feature类型的HAP包

依赖规则：

• 可以横向调用及依赖commons层
• 可以被products层不同设备形态的HAP所依赖
• 不能反向依赖products层
• features之间可以有限度的横向调用

目录示例：

3. products（产品定制层）

用于针对不同设备形态进行功能和特性集成。products层各个子目录各自编译为一个Entry类型的HAP包，作为应用主入口。products层不可以横向调用。

定位：针对不同设备形态进行功能和特性集成

职责：

• 作为应用主入口
• 集成features层的各个功能模块
• 针对不同设备进行UI适配和功能定制

编译形式：Entry类型的HAP包

依赖规则：

• 可以依赖commons层和features层
• 不可以横向调用其他product模块
• 不可以被其他层反向依赖

目录示例：

工程目录迁移

根据三层工程架构示意图配置工程目录

步骤一：

根据第二节的三层工程架构示意图，首先在工程目录Project下，创建三个文件夹commons、features、products。

步骤二：

在features目录下创建三个模块，分别是quickstart、map、learning

步骤三：

创建commons层模块，与创建features层的模块一样，在commons文件夹中，创建两个模块utils和uicomponents，创建时同样选择Static Library，这两个模块存放一些公用的工具或者ui组件，在需要用到时使用

步骤四：

将entry模块放入products层，products层主要根据产品定制层内结构，这里我们需要将工程名改成default，通过右键选择refactor-> rename，选择Rename module

原工程迁移至quickstart模块

步骤1：

原来entry模块中的功能，都只是quickstart模块对应的功能，需要将entry对应的文件复制到quickstart模块中

步骤2：

将quickstart模块中的默认生成的components文件夹删除，其他模块也建议一并删除默认内容，需要使用时再根据具体的目录结构进行创建。

步骤3：

同时需要删除对应模块内Index.ets文件里面的导出声明export语句，因为对应的MainPage已经被删除。

步骤4：

将default模块中pages、model、util、view移入quickstart模块的ets目录中

步骤5：

将default模块中rawfile移入quickstart模块的resources资源目录中

products层配置修改

步骤1：

接下来需要对文件结构进行调整，由于default内的pages移走，需要重新创建一个pages目录，用于应用的根页面，并新建一个page页面

步骤2：

在pages中右键新建一个empty page并命名为Index

步骤3：

此时自动在main_page.json中自动生成一个页面配置pages/Index，由于默认工程初始包含了Index页面（之前移入了quickstart模块中），在这里需要删除重复的页面配置。

products层引用quickstart模块

步骤1：

在quickstart模块中，找到Index.ets，并修改名称为QuickStartPage，同时需要删除页面上的@Entry标识

步骤2：

为了让其他模块能够引用到这个组件，还需要使用export导出这个组件

步骤3：

在quickstart模块中，根目录下找到Index.ets，这个文件的作用是统一导出该模块内，需要导出的UI组件或者类等内容
在Index.ets中导出QuickStartPage，这样其他模块就能够访问到quickstart模块中的组件

步骤4：

回到default模块中，这个模块是整个工程的顶级模块，其依赖底下的features层内模块，现在可以配置依赖，让其可以使用quickstart内的组件并展示
在default模块的oh-package.json5文件中，写入以下依赖内容，这里需要注意不是工程级别的oh-package.json，需要先找到default模块
在oh-package.json5文件中，dependencies中写入对quickstart模块的依赖，因为后续还会使用map和learning模块的内容，这里一并配置好依赖，方便后续使用。

步骤5：

配置完后，会提示需要安装依赖，可以通过Run "ohpm install"执行安装过程。

步骤6：

在default模块中的pages/Index.ets中，清除build函数内默认的内容

步骤7：

在Index中引入QuickStartPage，并且在build方法中新增Column组件，在Column中使用QuickStartPage展示快速入门的内容。

总结

三层工程架构为HarmonyOS应用开发提供了清晰、可维护、可扩展的工程组织方案。通过将应用划分为commons、features、products三个层次，不仅解决了传统单层结构的各种问题，还为团队协作、功能扩展和多设备适配提供了良好的基础。

在实际项目中，建议根据具体业务需求和团队规模适当调整架构细节，但保持层次清晰和依赖规范的原则不变。这种架构模式尤其适合中大型HarmonyOS应用项目的开发，能够显著提高开发效率和代码质量。