整洁架构中的“依赖规则”即所有的代码都必须依赖抽象，而抽象不能依赖具体实现。这意味着，更内层的圆圈（代表更高抽象层次）不应知道任何关于外层圆圈（代表较低、更具体层次）的细节。依赖方向总是从外向内。具体来说，实体层（领域模型）、用例层（应用逻辑）和接口适配器层（如Web API, Repository Adapters等）应该遵循这一原则。例如，如果有一个UserRepository接口定义在应用层，用于声明访问用户信息的合同，那么具体的实现类如MySqlUserRepository应该在基础设施层中实现这个接口。这样，用例（或服务层）只依赖于UserRepository抽象接口，而不需要关心数据是从数据库、文件或其他任何形式获取的。

依赖规则通过确保系统的各个部分只依赖于抽象，而不是具体实现，促进了高度解耦的设计。这种解耦使系统更容易适应变化，如更换数据库、修改用户界面或引入新的第三方服务，而不必对系统的核心逻辑做出重大修改。当业务需求发生变化或技术栈需要升级时，开发人员可以更容易地在不破坏现有系统结构的情况下进行调整。此外，这种设计也有助于提高代码的可测试性，因为可以轻松地为抽象接口提供模拟实现，从而在不影响其他模块的情况下测试特定功能。

例如，假设我们正在构建一个在线商城应用，采用整洁架构模式。在这个场景中，购物车的逻辑可能位于用例层，而持久化相关操作则在基础设施层处理。为了遵循依赖规则，我们可以定义一个CartRepository接口在用例层，然后在基础设施层提供具体的数据库实现。如果未来需要将数据存储从关系数据库切换到NoSQL数据库，我们仅需修改CartRepository的实现类，而无需更改任何用例层的代码。这不仅提高了系统的灵活性，还简化了未来的维护工作。