4.Clean Architecture：架构与系统边界能力提炼

[1. 架构到底是什么？](#1. 架构到底是什么？)
[2. Clean Architecture 的核心](#2. Clean Architecture 的核心)
[3. Dependency Rule：依赖规则](#3. Dependency Rule：依赖规则)
[4. Entity / Domain](#4. Entity / Domain)
[5. Use Case / Application](#5. Use Case / Application)
[6. Infrastructure](#6. Infrastructure)
[7. Interface Adapter](#7. Interface Adapter)
[8. 为什么架构需要"边界"？](#8. 为什么架构需要“边界”？)
[9. 不要机械套 Clean Architecture](#9. 不要机械套 Clean Architecture)
[10. 架构设计最重要的问题](#10. 架构设计最重要的问题)
[11. GIS + Electron 的架构思考](#11. GIS + Electron 的架构思考)
[12. 架构与产品设计](#12. 架构与产品设计)
[13. AI Coding 中如何使用 Clean Architecture 思维？](#13. AI Coding 中如何使用 Clean Architecture 思维？)
[14. 本阶段最终能力](#14. 本阶段最终能力)

第四阶段学习目标：从"如何组织代码"进一步进入"如何组织整个软件系统"。

核心问题：

当项目越来越大时，模块、业务、UI、数据库、第三方 SDK 应该如何划分边界？

1. 架构到底是什么？

很多人理解架构是：

text 复制代码

目录怎么分
类怎么分
用了什么框架

更重要的理解是：

架构是在管理系统中的依赖关系和变化。

也就是说：

text 复制代码

谁依赖谁？
谁可以知道谁？
什么东西可以替换？
什么东西应该稳定？

2. Clean Architecture 的核心

可以先用一个简化模型理解：

text 复制代码

        UI / Framework
              ↓
       Application
              ↓
           Domain
              ↑
       Infrastructure

核心思想不是某个固定目录，而是：

核心业务逻辑不要被外部技术细节绑死。

例如：

text 复制代码

业务规则
   ↑
应用服务
   ↑
UI / Electron
   ↑
Cesium / 文件系统 / 数据库

更准确地说：

依赖应该朝向稳定的业务规则，而不是让业务规则依赖具体技术。

3. Dependency Rule：依赖规则

最重要的思想：

text 复制代码

外部细节
   ↓
内部规则

而不是：

text 复制代码

业务逻辑
 ↓
直接依赖
 ↓
某个具体数据库 / UI / SDK

例如：

text 复制代码

ModelService

最好不要到处直接调用：

text 复制代码

Cesium API
Electron API
Node fs
ZMQ

可以通过边界隔离。

4. Entity / Domain

Domain 代表：

系统真正的业务概念和业务规则。

GIS 项目中的例子：

text 复制代码

Project
Layer
Model
Terrain
Coordinate
AnalysisTask

业务规则例如：

text 复制代码

一个项目可以包含多个图层
模型必须属于某个项目
某些坐标系之间可以转换
分析任务具有生命周期

这些规则不应该完全依赖某个 UI 框架。

5. Use Case / Application

Application 层描述：

系统可以完成什么业务操作。

例如：

text 复制代码

CreateProject
OpenProject
LoadModel
RemoveLayer
RunAnalysis
ExportResult

它负责组织业务流程。

6. Infrastructure

Infrastructure 是具体技术实现：

text 复制代码

FileSystem
Database
Cesium
ZMQ
HTTP
Electron
AI API

这些东西都可能变化。

因此应该尽量与业务核心隔离。

7. Interface Adapter

这一层负责：

把外部世界的数据转换成系统内部可以理解的形式。

例如：

text 复制代码

Electron IPC
   ↓
IPC Adapter
   ↓
Application Service

或者：

text 复制代码

Cesium
   ↓
GIS Adapter
   ↓
Domain / Application

8. 为什么架构需要"边界"？

假设：

text 复制代码

业务代码
 ↓
Cesium API

那么以后换 GIS 引擎：

text 复制代码

Cesium
 ↓
换成其他 GIS Engine

可能导致大量业务代码修改。

如果：

text 复制代码

业务
 ↓
GIS Interface
 ↓
Cesium Adapter

那么更换实现时：

text 复制代码

Cesium Adapter
 ↓
OtherGIS Adapter

业务层可以基本保持不变。

9. 不要机械套 Clean Architecture

非常重要：

Clean Architecture 是原则，不是目录模板。

不要为了它创建：

text 复制代码

domain/
application/
infrastructure/
adapter/
repository/
usecase/
entity/
factory/

然后一个简单功能需要十几个文件。

应该根据项目规模：

小项目

text 复制代码

feature/
 ├── service
 ├── component
 └── types

中型项目

开始建立：

text 复制代码

UI
Application
Domain
Infrastructure

大型系统

再进一步明确：

text 复制代码

领域
边界
服务
数据
基础设施
外部系统

10. 架构设计最重要的问题

以后设计系统时，可以固定问：

问题 1：核心业务是什么？

text 复制代码

什么东西即使换 UI 也应该存在？

问题 2：什么东西容易变化？

text 复制代码

UI
数据库
GIS SDK
网络协议
文件格式

问题 3：谁应该依赖谁？

问题 4：哪里应该建立接口？

问题 5：如果换技术，影响范围有多大？

问题 6：测试核心业务是否需要启动整个系统？

如果：

测试一个简单业务规则必须启动 Electron + GIS + 数据库。

通常说明边界存在问题。

11. GIS + Electron 的架构思考

可以逐渐形成这样的结构：

text 复制代码

Electron UI
     ↓
Application
     ↓
Domain / Interfaces
     ↑
Infrastructure
 ┌──────┬──────┬──────┐
 ↓      ↓      ↓
Cesium  FS     ZMQ

进一步：

text 复制代码

UI
 ↓ IPC
Application Service
 ↓
Domain
 ↓
Interfaces
 ↓
Infrastructure

这里不是要求你立刻重构项目。

重点是：

理解为什么需要边界。

12. 架构与产品设计

架构不是脱离产品的。

产品需求决定系统边界。

例如：

"用户可以加载模型。"

继续问：

text 复制代码

用户是否可以取消？
是否支持多个模型？
是否保存项目？
是否记住模型状态？
是否支持撤销？
是否支持远程模型？

这些产品问题最终都会影响：

状态设计
模块设计
数据模型
接口设计
系统架构

所以：

架构能力的一部分，其实来自产品理解能力。

13. AI Coding 中如何使用 Clean Architecture 思维？

让 AI 先分析：

text 复制代码

请分析当前项目的依赖关系。

输出：
1. 核心业务模块
2. UI 模块
3. 基础设施
4. 第三方依赖
5. 当前依赖方向
6. 高风险耦合点

不要修改代码。

然后：

text 复制代码

如果未来需要把 Cesium 替换成其他 GIS Engine，
当前架构哪些地方会受到影响？

请给出最小改造方案。

这类问题比：

"帮我优化架构。"

更有价值。

14. 本阶段最终能力

最终要建立：

边界意识。

看到一个系统时，可以逐渐判断：

text 复制代码

核心业务在哪里？
        ↓
外部技术在哪里？
        ↓
它们之间的边界在哪里？
        ↓
依赖方向是否合理？
        ↓
未来变化会影响多少模块？

最终：

架构 = 控制依赖 + 隔离变化 + 管理复杂度。