一、实现背景
纯血鸿蒙官方推荐common、feature、products三层架构，本次在官方架构上做了简易实用性实践。
为满足集团内部多个不同业务APP集成相同功能SDK兼有不同程度定制化的需求，特将公共功能下沉到SDK的中间层featureA、featureB、featureC，将针对不同APP做UI层适配的功能提到最顶层feature模块（示例中为entry模块），业务APP只需集成最顶层feature模块（示例中为entry模块）。
二、环境参数
- OS: WINDOWS 10
- IDE: DevEco Studio 5.0.0 Release,Build Version: 5.0.3.910, built on November 1, 2024
- SDK: HarmonyOS 5.0.0 Release SDK, based on OpenHarmony SDK Ohos_sdk_public 5.0.0.71 (API Version 12 Release)
三、实现过程
1.基本思路
项目架构总体分为三层：product（产品定制层）、feature（基础特性层）、common（公共能力层）。
产品定制层（product）：
- 作为应用入口，负责用户直接互动的界面。
- 满足不同设备或场景的个性化需求，能独立运作，同时仅依赖基础特性层和公共能力层。
- 可灵活地调整和扩展，从而满足各种使用场景。
基础特性层（feature）：
- 在产品定制层之下，存放独立地功能UI和业务逻辑实现。具有高内聚、低耦合、可定制地特点，以支持产品地灵活部署
- 依赖下层地公共能力层为其提供通用功能和服务
- 可根据业务场景做相应模块化处理。例如：每个模块即应用底部导航栏中的一个tab
公共能力层（common）
- 用于存放公共基础能力，为上层提供稳定可靠的功能支持，提高整个应用的稳定性和可维护性
- 公共能力层包括但不限于以下组成：
- 公共UI组件（统一的交互：提示、警告、加载状态...）
- 数据管理（统一的存储和访问，包括应用数据、系统数据）
- 外部交互（网络请求、文件I/O 、设备I/O ...）
- 工具库（日志、字符串处理、日期处理...）
1.1 组件间源码依赖关系
项目组件源码层级关系：
项目组件间依赖关系：
公共能力层的utils属于最底层，被不同层模块所依赖使用。开发阶段，所有依赖都是源码依赖。
编译打包阶段，所有模块都是打包成独立SDK，所有依赖变成对应的har或者tgz依赖。
备注：为避免不同common或feature各自依赖一份utils.hsp，本次实践utils为集成态HSP模块。utils模块在编译后，会生成utils.har + utils-defatut.tgz。中间层依赖utils时只需依赖utils.har接口定义包，最顶层依赖utils-default.tgz实现包。
1.2 组件打包编译后关系
此时仅需对外提供一份SDK文件，即featureTop组件，组件内按需集成featureA、feaureB、featureC，然后打包featureTop.har发布给三方使用。
entryA、entryB在此处可以视为SDK demo，在对外发布前，用于调试SDK内部功能是否正常。
1.3 多模块辅助功能
- 多模块多层级依赖在本地打包时，会出现需要手动替换har包依赖问题，此时借助脚本动态修改依赖并打包模块会显著提升（windows的powershell脚本，mac\linux的shell脚本）
- feature模块间API调用有时候是必不可少的，可以借助router或emitter实现
