Clean Architecture

1. 软件架构旨在最小化人力资源并最大化生产力

软件架构的目标是最小化构建和维护所需系统的人力资源。

架构决策至关重要。 良好的架构可以减少开发、部署和维护软件系统所需的努力。它允许团队独立工作，最小化变更的影响，并使系统随着时间的推移不断演进。

良好架构的关键方面：

• 关注点分离
• 依赖管理
• 实现细节的抽象
• 适应未来变化的灵活性

通过关注这些方面，架构师可以创建更易于理解、修改和扩展的系统，最终提高生产力并降低系统生命周期内的成本。

2. 清晰架构将业务规则与外部细节分离

应用程序的中心不是数据库，也不是你可能使用的一个或多个框架。应用程序的中心是应用程序的用例。

业务规则是核心。 清晰架构将代码组织成同心圆，业务规则在中心，实施细节在外层。这种分离使核心业务逻辑不受外部因素（如数据库、用户界面或框架）变化的影响。

清晰架构的关键层次：

• 实体：企业范围的业务规则
• 用例：特定应用程序的业务规则
• 接口适配器：在用例和外部机构之间转换数据
• 框架和驱动程序：外部工具和技术

遵循这种结构，开发人员可以创建：

• 更灵活和适应变化的系统
• 更易于测试和维护的系统
• 对特定技术或框架依赖性较小的系统

3. SOLID原则指导创建灵活、可维护的系统

SOLID原则告诉我们如何将函数和数据结构安排到类中，以及这些类应该如何互连。

SOLID增强模块化。 这五个原则为创建更易理解、灵活和可维护的软件系统提供了指导。它们帮助开发人员设计出对变化具有抵抗力且易于扩展的代码。

SOLID原则包括：

• 单一职责原则：一个类应该只有一个改变的理由
• 开放-封闭原则：软件实体应该对扩展开放，但对修改封闭
• 里氏替换原则：超类的对象应该可以被其子类的对象替换，而不影响程序的正确性
• 接口隔离原则：多个特定客户端的接口优于一个通用接口
• 依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象

通过应用这些原则，开发人员可以创建更健壮和可扩展的软件架构，能够适应不断变化的需求。

4. 组件是清晰架构的构建块

组件是部署的单位。它们是可以作为系统的一部分独立部署的最小实体。

模块化设计实现灵活性。 清晰架构中的组件是可以独立部署和开发的系统部分。它们封装了相关功能并具有明确的接口，从而使系统的维护和修改更加容易。

设计良好的组件的关键特征：

• 高内聚：相关功能集中在一起
• 低耦合：组件之间的依赖最小
• 明确的接口：定义良好的交互方法
• 独立部署：可以更新或替换而不影响系统的其他部分

通过将系统组织成组件，架构师可以：

• 促进不同团队的并行开发
• 更容易进行测试和调试
• 允许系统的增量更新和改进
• 提高系统的整体可扩展性和可维护性

5. 边界定义并保护核心业务逻辑

在每个架构边界，我们可能会发现谦逊对象模式潜伏在某处。

边界保护核心。 清晰架构中的架构边界将不同的关注点分开，特别是业务逻辑和实现细节之间的分离。这些边界有助于保持核心业务规则不受外部系统或技术变化的影响。

架构边界的关键方面：

• 使用接口定义层之间的交互
• 依赖倒置确保依赖指向内部
• 数据传输对象在边界之间传递信息
• 谦逊对象将可测试行为与难以测试的组件分离

通过建立明确的边界，架构师可以：

• 最小化外部系统或技术变化的影响
• 更容易测试核心业务逻辑
• 在不影响核心系统的情况下替换实现细节
• 提高系统的整体灵活性和适应性

6. 清晰架构促进测试驱动开发和独立部署

一个好的架构使系统在所有必须改变的方式上都易于改变，通过保持选项开放。

可测试性和灵活性是关键。 清晰架构促进了使系统更易于测试和独立部署的实践。通过分离关注点和管理依赖关系，编写核心业务逻辑的单元测试变得更加简单，并且可以单独部署系统的不同组件。

清晰架构在测试和部署方面的好处：

• 核心业务规则可以在没有UI、数据库或外部依赖的情况下进行测试
• 不同组件可以独立部署，便于更新
• 系统某一部分的变化对其他部分的影响最小
• 新功能可以在不破坏现有功能的情况下添加

这些特性带来：

• 更快的开发周期
• 部署风险降低
• 系统可靠性提高
• 更灵活地采用新技术或更改现有技术

7. 框架和数据库是实现细节，而不是架构元素

框架是工具，而不是必须遵循的架构。

核心逻辑应与框架无关。 清晰架构将框架和数据库视为不应影响核心业务逻辑的外部细节。这种方法允许在不影响系统核心功能的情况下更改或更新这些外部元素。

处理框架和数据库的关键原则：

• 将它们视为核心业务逻辑的插件
• 使用依赖倒置保持核心逻辑独立
• 为数据库操作创建抽象
• 尽可能推迟框架和数据库的决策

这种方法的好处：

• 更容易更改或升级框架和数据库
• 核心业务逻辑在外部变化中保持稳定
• 减少供应商锁定
• 提高核心系统组件的可测试性

8. 在清晰架构中，Web只是另一种交付机制

Web是一种交付机制，你的应用程序架构应该将其视为如此。

业务逻辑与交付无关。 在清晰架构中，Web被视为一种外部细节，类似于数据库或框架。这种观点使核心业务逻辑独立于特定的交付机制，无论是Web应用程序、桌面应用程序还是API。

清晰架构中Web应用程序的关键考虑：

• 将特定于Web的代码与核心业务逻辑分离
• 使用接口适配器在Web格式和内部数据结构之间转换
• 将Web框架视为核心系统的插件
• 设计用例独立于Web特定问题

这种方法的好处：

• 更容易将系统适应不同的交付机制
• 核心业务逻辑可以在多个平台上重用
• 简化了没有Web依赖的业务规则测试
• 更灵活地更改或更新Web技术

9. 清晰嵌入式架构将硬件问题与业务逻辑分离

尽管软件不会磨损，但它可能会因对硬件的未管理依赖而从内部被破坏。

硬件独立性至关重要。 清晰嵌入式架构将清晰架构的原则应用于嵌入式系统，将硬件特定问题与核心业务逻辑分离。这种分离使硬件组件的更新更容易，软件的可移植性更强。

清晰嵌入式架构的关键要素：

• 硬件抽象层（HAL）隔离硬件特定代码
• 设备无关的业务逻辑
• 硬件和软件组件之间的明确接口
• 使用依赖倒置管理硬件依赖

这种方法在嵌入式系统中的好处：

• 更容易将软件移植到新硬件平台
• 简化了没有硬件依赖的核心逻辑测试
• 硬件变化对整体系统的影响减少
• 提高嵌入式软件的可维护性和寿命

10. 微服务和面向服务的架构可以从清晰架构原则中受益

系统的架构由将软件元素彼此分开的边界定义，并限制一侧的元素了解另一侧的元素。

清晰原则适用于所有规模。 虽然清晰架构通常在单体应用程序的上下文中讨论，但其原则可以有效地应用于微服务和面向服务的架构。这些原则有助于保持单个服务的独立性和可测试性，同时管理分布式系统的复杂性。

将清晰架构应用于微服务：

• 将每个微服务视为具有自身清晰架构的边界上下文
• 使用定义良好的接口进行服务间通信
• 在服务之间应用依赖倒置
• 保持服务的独立部署

清晰架构在微服务中的好处：

• 提高整体系统的模块化和可扩展性
• 更容易理解和维护单个服务
• 更灵活地演进和替换服务
• 减少服务之间的耦合，导致更健壮的系统

最后更新日期: July 26, 2024