目录1. 架构到底是什么2. Clean Architecture 的核心3. Dependency Rule依赖规则4. Entity / Domain5. Use Case / Application6. Infrastructure7. Interface Adapter8. 为什么架构需要“边界”9. 不要机械套 Clean Architecture10. 架构设计最重要的问题11. GIS Electron 的架构思考12. 架构与产品设计13. AI Coding 中如何使用 Clean Architecture 思维14. 本阶段最终能力第四阶段学习目标从“如何组织代码”进一步进入“如何组织整个软件系统”。核心问题当项目越来越大时模块、业务、UI、数据库、第三方 SDK 应该如何划分边界1. 架构到底是什么很多人理解架构是目录怎么分 类怎么分 用了什么框架更重要的理解是架构是在管理系统中的依赖关系和变化。也就是说谁依赖谁 谁可以知道谁 什么东西可以替换 什么东西应该稳定2. Clean Architecture 的核心可以先用一个简化模型理解UI / Framework ↓ Application ↓ Domain ↑ Infrastructure核心思想不是某个固定目录而是核心业务逻辑不要被外部技术细节绑死。例如业务规则 ↑ 应用服务 ↑ UI / Electron ↑ Cesium / 文件系统 / 数据库更准确地说依赖应该朝向稳定的业务规则而不是让业务规则依赖具体技术。3. Dependency Rule依赖规则最重要的思想外部细节 ↓ 内部规则而不是业务逻辑 ↓ 直接依赖 ↓ 某个具体数据库 / UI / SDK例如ModelService最好不要到处直接调用Cesium API Electron API Node fs ZMQ可以通过边界隔离。4. Entity / DomainDomain 代表系统真正的业务概念和业务规则。GIS 项目中的例子Project Layer Model Terrain Coordinate AnalysisTask业务规则例如一个项目可以包含多个图层 模型必须属于某个项目 某些坐标系之间可以转换 分析任务具有生命周期这些规则不应该完全依赖某个 UI 框架。5. Use Case / ApplicationApplication 层描述系统可以完成什么业务操作。例如CreateProject OpenProject LoadModel RemoveLayer RunAnalysis ExportResult它负责组织业务流程。6. InfrastructureInfrastructure 是具体技术实现FileSystem Database Cesium ZMQ HTTP Electron AI API这些东西都可能变化。因此应该尽量与业务核心隔离。7. Interface Adapter这一层负责把外部世界的数据转换成系统内部可以理解的形式。例如Electron IPC ↓ IPC Adapter ↓ Application Service或者Cesium ↓ GIS Adapter ↓ Domain / Application8. 为什么架构需要“边界”假设业务代码 ↓ Cesium API那么以后换 GIS 引擎Cesium ↓ 换成其他 GIS Engine可能导致大量业务代码修改。如果业务 ↓ GIS Interface ↓ Cesium Adapter那么更换实现时Cesium Adapter ↓ OtherGIS Adapter业务层可以基本保持不变。9. 不要机械套 Clean Architecture非常重要Clean Architecture 是原则不是目录模板。不要为了它创建domain/ application/ infrastructure/ adapter/ repository/ usecase/ entity/ factory/然后一个简单功能需要十几个文件。应该根据项目规模小项目feature/ ├── service ├── component └── types中型项目开始建立UI Application Domain Infrastructure大型系统再进一步明确领域 边界 服务 数据 基础设施 外部系统10. 架构设计最重要的问题以后设计系统时可以固定问问题 1核心业务是什么什么东西即使换 UI 也应该存在问题 2什么东西容易变化UI 数据库 GIS SDK 网络协议 文件格式问题 3谁应该依赖谁问题 4哪里应该建立接口问题 5如果换技术影响范围有多大问题 6测试核心业务是否需要启动整个系统如果测试一个简单业务规则必须启动 Electron GIS 数据库。通常说明边界存在问题。11. GIS Electron 的架构思考可以逐渐形成这样的结构Electron UI ↓ Application ↓ Domain / Interfaces ↑ Infrastructure ┌──────┬──────┬──────┐ ↓ ↓ ↓ Cesium FS ZMQ进一步UI ↓ IPC Application Service ↓ Domain ↓ Interfaces ↓ Infrastructure这里不是要求你立刻重构项目。重点是理解为什么需要边界。12. 架构与产品设计架构不是脱离产品的。产品需求决定系统边界。例如“用户可以加载模型。”继续问用户是否可以取消 是否支持多个模型 是否保存项目 是否记住模型状态 是否支持撤销 是否支持远程模型这些产品问题最终都会影响状态设计模块设计数据模型接口设计系统架构所以架构能力的一部分其实来自产品理解能力。13. AI Coding 中如何使用 Clean Architecture 思维让 AI 先分析请分析当前项目的依赖关系。 输出 1. 核心业务模块 2. UI 模块 3. 基础设施 4. 第三方依赖 5. 当前依赖方向 6. 高风险耦合点 不要修改代码。然后如果未来需要把 Cesium 替换成其他 GIS Engine 当前架构哪些地方会受到影响 请给出最小改造方案。这类问题比“帮我优化架构。”更有价值。14. 本阶段最终能力最终要建立边界意识。看到一个系统时可以逐渐判断核心业务在哪里 ↓ 外部技术在哪里 ↓ 它们之间的边界在哪里 ↓ 依赖方向是否合理 ↓ 未来变化会影响多少模块最终架构 控制依赖 隔离变化 管理复杂度。