OpenEmber 架构概览
OpenEmber 采用清晰的五层模型（依赖自上而下），便于扩展与长期维护：
- Application Layer — 可执行入口与编排（产品应用、系统节点、可选服务、示例、工具）
- Module Layer — 插件式功能扩展（传输后端、驱动、桥接、应用模块等）
- Component Layer — 跨模块复用组件（日志、算法、序列化、容器、配置解析等）
- Core Layer — 中间件运行时（节点生命周期、调度、话题、参数、服务等）
- Platform Layer — 操作系统抽象与 HAL（线程、定时器、socket、UART、GPIO、I2C 等）
Application 在逻辑上是一层；仓库里按职责拆成多个顶层目录，而不是额外架构层：
| 目录 | 角色 |
|---|---|
apps/ | 产品或用户项目入口（框架自带节点不放这里） |
system/ | OpenEmber 自带、偏必需的系统节点 |
services/ | 可选 runtime 服务 |
examples/ | 示例与参考实现 |
tools/ | 开发、调试、运维工具 |
其下各层目录大致对应 modules/、components/、core/、platform/。另有 third_party/、configs/ 等工程辅助目录。
在 menuconfig 中，顶层菜单按工程使用体验做了收敛：
Build / Toolchain
Application Layer
Middleware
Components
Platform
Third party
Tests
其中 Application Layer 聚合 apps/、system/、services/、examples/、tools/。当前 modules/ 目录保留为未来扩展槽；由于暂时没有独立配置项，不再作为顶层菜单显示。
Middleware 聚合通信与核心运行时配置，例如 Communication、Core Runtime。
依赖方向
Application（apps / system / services / examples / tools）
↓
modules
↓
components
↓
core
↓
platform
↓
操作系统（Linux 等）
上层可依赖下层，避免反向依赖，便于单独测试与替换实现（例如更换传输后端或 HAL 后端）。
组件层常用能力包括日志（Logging）、Algorithm、Thread Pool 等；通信层见 OpenEmber Link。
设计思想（摘要）
- 可扩展：插件化模块与 Kconfig 裁剪，适配不同产品与算力。
- 依赖管理：
OPENEMBER_THIRD_PARTY_MODE等选项支持 FETCH / VENDOR / SYSTEM，兼顾离线与企业构建。 - 通信抽象：OpenEmber Link 提供稳定的 Topic、Service、Liveliness 和消息编解码语义，底层传输实现对应用隐藏。
更完整的分层说明见上游 分层设计文档 与 Application 层设计指导；通信层见 OpenEmber Link。