核心思想一般都总结成：关注点分离，依赖反转。
我理解就是：
程序的核心部分是业务逻辑，业务逻辑应该是清晰准确的表达。
业务逻辑应该和实现细节彻底隔离，避免业务逻辑受到实现细节调整的影响。
- 框架隔离：业务逻辑和框架解耦，无论切换到什么框架，业务逻辑无需变化
- UI 隔离：无论使用什么 UI，Web UI 也好，某个图形库也好，命令行也好，业务逻辑无需变化
- 数据库隔离：切换数据库的成本就是封装外围数据操作接口，业务逻辑无需变化
- 外部依赖隔离：外部依赖提供的功能被封装，切换依赖也不会影响到业务逻辑
我就觉得应该通过分层，封装，最终的核心逻辑应该是非常简练的一段代码，就好像把大象装冰箱一样简单：打开冰箱，把大象放进去，关上冰箱。
好处是：
- 代码结构清晰整洁，容易阅读，容易测试，容易维护
- 核心逻辑简单明确，稳定可靠，不容易出严重问题
- 方便调整外部实现，更加灵活
核心概念与实现
-
Entities（实体层）
代表业务核心规则或领域模型，纯粹的对象，不依赖其他层。这一层的职责是定义系统的业务规则，保证其独立性和复用性。 -
Use Cases（用例层）
定义具体的业务流程，协调 Entities 来完成系统的功能需求。这一层负责系统的行为逻辑，并确保业务规则得以正确执行。 -
Interface Adapters（接口适配器层）
负责将外部世界的数据转化为系统可以理解的形式，或者将系统的数据转化为外部需要的形式。这一层包括控制器、Presenter 和 ViewModel。 -
Frameworks & Drivers（框架与驱动层）
最外层，包含数据库、UI、第三方服务等实现细节。它们是可替换的，不影响核心业务逻辑。
实现的三个关键原则
-
依赖规则（Dependency Rule）
依赖只能指向内层，外层不能直接调用内层的实现。通过依赖反转原则（DIP），核心业务逻辑完全摆脱了对实现细节的依赖。 -
边界抽象（Boundary Abstraction）
内层通过接口定义与外层的交互边界，外层实现这些接口。这样，业务逻辑可以独立于外部框架或工具运行。 -
测试友好性（Testability）
因为核心逻辑不依赖外部框架或技术，单元测试可以专注于纯粹的业务逻辑，减少测试复杂度。
