架构设计系列 5：常见架构介绍

前面讲了架构是什么，架构的发展史，架构设计的基础理论，这次针对常见架构设计风格进行介绍和分析。

一、MVC：三层架构经典

经典的 MVC 架构（Model-View-Controller）架构是软件系统架构设计中的经典，它将应用程序分为三个主要部分：

1. 模型（Model）

2. 视图（View）

3. 控制器（Controller）

这样的三层架构有助于实现业务逻辑的分离，提高代码的可维护性和可扩展性。

关于 MVC 的架构细节这里就不做过多介绍，有兴趣的各位可以自行查询相关资料，类似资料有很多，不过现阶段技术类型的公司已经几乎不再使用 MVC 的三层架构了。

二、CQRS：命令查询职责分离

命令查询职责分离模式（Command Query Responsibility Segregation，CQRS）是一种软件架构模式，它通过从业务上分离修改（Command：增、删、改，会对系统状态进行修改）和查询（Query：查，不会对系统状态进行修改）的行为，使逻辑清晰，提高系统的可维护性和灵活性。

优点

1. 业务逻辑清晰：将修改和查询操作分开，使业务逻辑更加清晰。命令负责修改状态，而查询负责获取信息，降低系统复杂性

2. 可维护性增强：通过将写模型和读模型分离，可以独立演化和优化两者。提高了系统的可维护性，开发人员可以更容易地理解和修改两个模型

3. 扩展性：支持根据系统需求独立扩展命令和查询部分，这种灵活性使得系统更容易适应不断变化的需求

4. 更好的性能优化：通过专门优化读模型，可以更好地满足查询性能的需求，有助于提高系统的整体性能

不足

1. 结构复杂：引入两个独立的模型（读写），使得系统结构复杂度高，维护和理解这两个模型之间的关系可能需要更多的工作

2. 冗余代码：由于存在独立的读写模型，可能导致代码冗余，特别是对于一些共享的业务逻辑，这需要谨慎的设计和维护，以避免冗余

3. 性能问题：涉及多次数据库操作，可能导致性能问题，特别是在需要频繁进行读写操作的情况下，需要根据具体情况进行性能优化

4. 工作流不直观：将任务分解为多个步骤，可能导致工作流难以理解，尤其是对于新加入的开发人员，文档和培训对于确保团队对工作流的理解至关重要

5. 缺乏标准化：并没有广泛的标准，团队在实践中需要根据自身需求进行调整，可能缺乏一致性和规范性

总

结

CQRS 命令查询职责分离

CQRS 是一个特定场景下有益的架构模式，但在引入时需要仔细权衡其优缺点。在对系统的可维护性、可扩展性和性能有较高要求的情况下，CQRS 可能是一个有价值的选择。然而，对于简单的应用程序，引入 CQRS 可能会增加不必要的复杂性。在实践中，团队应该根据具体情况慎重考虑是否采用 CQRS 。

三、六边形架构

六边形架构（Hexagonal Architecture）也称为端口适配器模式，是 Alistair Cockburn 在 2005 年首次提出的一种软件架构模式。其主要目标是将应用程序的核心逻辑与特定的输入/输出技术解耦，使其能够更灵活的应对变化和演化。

三个原则

明确分层层次（ Explicitly separate Application，Domain，and Infrastructure**）**

在六边形架构中，明确分离应用程序（Application）、领域（Domain）和基础设施（Infrastructure）是关键的设计原则，这种分离使开发者将关注点分离开，每一层都可以独立变化而不影响其他层，提高了系统的可维护性、可测试性和可扩展性。

应用程序层

Application Layer

责任：包含应用程序的业务逻辑，负责协调领域层和基础设施层的交互，不包含具体的业务规则，而是将请求委托给领域层进行处理

实现：通常由应用服务组成，提供用例的实现，负责接收外部请求、处理输入数据、协调领域层的操作，并调用适当的基础设施服务

领域层

Domain Layer

责任：包含系统的核心业务逻辑和领域模型，这是系统的灵魂，包含了问题域的概念、规则和约束

实现：由实体（Entities）、值对象（Value Objects）、聚合（Aggregates）、领域服务（Domain Services）等构成，协调工作，实现业务规则，确保系统的行为符合领域的要求

基础设施层

Infrastructure Layer

责任：负责处理与外部系统的通信、数据库访问、日志记录等与具体技术相关的事务，包含所有与技术实现有关的组件

实现 ：包括数据库访问层、外部服务通信层、日志记录、配置等，这些组件对系统的业务逻辑是透明的，通过接口与应用程序层和领域层进行交互

依赖关系指向领域层（ Dependencies are going from Application and infrastructure to the Domain**）**

确保领域层保持独立性，不依赖于具体的应用程序逻辑或基础设施技术，提高系统的可测试性、可维护性和可扩展性。

技术上，就是 Application 和 Infrastructure 都不能直接互相调用对方的功能或者操作，只有经过 Domain 的接口才能沟通，确保 Domain 部分具有完整的独立性，不受 Application 和 Infrastructure 变更的影响，从而保持稳定，这样的代码结构易读、易管理、易维护。

依赖关系的方向

灸哥漫谈 期待你的关注

1. 应用程序层向领域层的依赖：应用程序层包含用例的实现，负责协调系统的操作并调用领域层的服务

2. 基础设施层向领域层的依赖：基础设施层包含与技术实现相关的组件，领域层不应该直接依赖于这些具体的技术实现，而是通过接口定义领域层所需的服务，并由基础设施层来实现这些接口

实现方式

灸哥漫谈 期待你的关注

1. 领域服务接口：在领域层中定义接口，描述领域服务的行为，这些接口是应用程序层和基础设施层依赖的抽象 ➡️ 如果领域层需要使用某种外部服务，可以在领域层定义一个接口，然后在基础设施层中实现这个接口

2. 依赖反转：通过依赖反转原则，应用程序层和基础设施层不直接依赖于领域层的具体实现，而是依赖于领域层定义的接口和抽象，这会让领域层能独立于其他层进行演化，不受具体实现细节的影响

3. 测试驱动开发：将依赖关系的方向设计成从应用程序和基础设施指向领域，有助于采用 TDD，通过在应用程序层和基础设施层编写测试用例，并通过模拟或替代领域层的具体实现，可以更容易进行单元测试，确保领域层的正确性

使用端口和适配器隔离边界（We isolate the boundaries by using Ports and Adapters）

六边形架构使用端口和适配器模式来隔离系统的边界，以提高系统的可测试性、可维护性和灵活性，目标是将业务逻辑与外部环境解耦，让系统的各个部分更容易替换、测试和理解。

基本概念

灸哥漫谈 期待你的关注

端口：定义系统与外界通信的接口，表示系统的一种能力或服务，通常通过接口来表示，定义系统对外提供的服务，不关心具体的实现，只关注服务的契约。

适配器：连接系统内部和外部的组件，负责将系统内的数据结构或接口转换成外部系统期望的形式，是外部环境和系统内部通信的桥梁，确保系统的核心业务逻辑不受业务环境的影响。

具体应用

灸哥漫谈 期待你的关注

内部端口和适配器：将应用程序划分为核心业务逻辑（Application）和外部环境（Infrastructure）两部分，内部端口表示系统对外部环境提供的服务，而内部适配器则负责将内部数据结构适应外部环境的需求。

外部端口和适配器：外部端口表示系统对外部环境的依赖，而外部适配器则将外部环境的服务适配成系统内部期望的形式，使系统的核心业务逻辑不直接依赖于具体的外部实现，而是通过端口和适配器与外部环境进行通信。

特点

对称性：系统的设计围绕着一个中心的应用核

心组件，所有的交互都必须通过这个中心

隔离性：应用程序的核心组件被一层薄的适配

器包围，使得它对外部环境的变化免疫

可插拔性：系统可以通过改变其适配器来更改

接口，并适应不同的上下文

组成部分

1. 应用核心：整个架构的心脏，包含了应用程序的业务逻辑和领域模型，不依赖任何特定的外部元素，只关注应用程序的核心功能

2. 端口：是应用程序核心向外提供的接口，定义了应用程序如何与外部世界进行通信

3. 适配器：用于连接应用程序核心和外部世界的栋梁，实现了端口的具体行为，并将请求路由到正确的位置

好处

1. 灵活性：当外部环境发生变化时，只需要修改适配器即可，而无需触及应用程序的核心

2. 测试友好：可以轻松模拟和替换适配器，从而更容易测试应用程序的核心部分

3. 低耦合：应用程序的核心部分与外部环境完全解耦，使其更易于维护和扩展

不足

1. 设计复杂度高

2. 需要花费更多时间进行需求分析和设计

3. 学习曲线比较陡峭，需要具备一定的软件设计知识

总

结

六边形架构

六边形架构是一种有助于提高代码代码质量和维护性的设计方式，但它也有一定的学习成本和实施难度。在实际应用中，可以根据具体项目的规模和复杂程度以及团队的技术能力，灵活运用此模式。

四、洋葱架构

洋葱架构（Onion Architecture）是由 2008 年，Jeffrey Palermo 提出，它在端口和适配器架构的基础上将领域放在应用中心，将用户用例和基础设施放在外围，这种设计思路类似于六边形架构，都是通过适配器代码将应用核心从对基础设施的关注中解放出来，以避免基础设施代码渗透到应用核心之中，使得框架和中间件需要改变替换的时候更加轻松，不会影响到核心领域。

设计原则

1. 依赖性：洋葱架构中的圆圈代表不同的责任层，进入越深越接近领域和业务规则，外圈代表机制，内圈代表核心领域逻辑，外层依赖于内层，而内层对外圈一无所知

2. 数据封装：每个圈层封装内部实现细节，向外层公开接口，在内层定义抽象接口，在外层提供具体实现，确保专注于领域模型，而不必过多地担心实现细节。运行时，可以使用依赖注入框架，将接口和实现连接起来

3. 关注点分离：应用系统被分为多个层级，每一个层级都有一组职责，并解决不同的关注点

4. 耦合性：低耦合性，一个模块和另一个模块交互时不需要关注另一个模块的内部具体实现，所有的内部层级不需要关注外部层级的具体实现

架构分层

1. 应用服务层：负责协调请求步骤的服务，不应该有任何业务逻辑，应用服务与其他服务交互来满足客户请求

2. 领域服务层：负责保持领域逻辑和业务规则，所有的业务逻辑应该作为领域服务的一部分来实现。领域服务由应用服务协调，服务于业务用例。不是简单的 CRUD 服务

3. 领域模型层：封装属性和实体行为

4. 基础设施层：在洋葱架构中的最外层，负责与外部世界交互，不解决任何领域的问题，没有任何逻辑

5. 可观察性服务层：负责监控应用，可以用于数据收集（指标、日志、痕迹）、数据存储、可视化等

优势

洋葱架构建立在一个领域模型上，各层之间通过接口交互，其设计思想是在领域实体和业务规则构成架构的核心部分时，尽可能将外部依赖性保持在外：

1. 提供灵活、可持续和可移植的架构

2. 各层之间没有紧密耦合，且有关注点的分离

3. 所有代码都依赖更深的层或者中心，提高可维护性

4. 提高整体代码的可测试性，单元测试可以在单独的层创建，不会影响其他的模块

5. 框架/技术可以容易改变而不影响核心领域

不足

1. 设计复杂性：多个端口和适配器需要额外的设计工作且增加了系统复杂度

2. 维护困难：洋葱架构的系统非常复杂对应的维护难度也比较高

总

结

洋葱架构

洋葱架构适用于大型、复杂的应用程序，对于需要长期维护和演进的系统，其设计理念有助于降低变更的风险，提高系统的可靠性和可扩展性，在具体应用时，可以根据项目规模和团队技术水平做出适当的调整。

五、DDD：领域驱动设计

领域驱动设计（Domain-Driven Design，DDD）是一种开发思想，强调将软件系统的注意力集中在业务领域上，将领域视为应用的核心。在架构设计中，DDD 提供了一种不同的思维方式，从以数据为中心的传统模型转向以业务领域为中心的模型。

核心概念

领域层

1. 对应于洋葱架构中的内层，是 DDD 中的核心

2. 在这一层，通过领域模型的建立，深入理解业务概念和规则

3. 通过建模，将专业领域的知识融入软件设计，实现软件系统与业务场景的紧密结合

领域模型

1. 用于捕捉业务概念和规则的模型

2. 通过建立领域模型，将业务领域的复杂性呈现在软件系统中，提高系统对业务的表达能力

实体对象/值对象/聚合对象

DDD 中的基本概念，用于构建领域模型

1. 实体表示具有唯一标识的对象

2. 值对象是没有唯一标识的对象

3. 聚合是一组相关对象的集合

优势

深入理解业务

1. 通过领域建模，开发团队能更深入理解业务需求和规则

2. 使软件系统更加贴近实际业务场景，提高系统的可理解性

可维护性

1. DDD 通过清晰的领域模型，降低了系统的复杂度

2. 模块化的设计使得系统更易于维护

适应性

领域模型的建立使得系统更加灵活，能够适应业务领域的变化

推荐阅读

《领域驱动设计：软件核心复杂性应对之道》（Eric Evans）DDD 的经典之作，详细介绍了如何通过领域驱动设计来理解和解决复杂软件系统中的问题。

国内也有一些作者写了关于 DDD 的书籍，但是很多都是基于这本书来的，有兴趣的也可以看看：《解构领域驱动设计》（张逸），这本书可能更好理解一点。

总

结

DDD

DDD 在当前业内基本上分为两个派系：

1. 理论派：重规范，重系统训练，以方法体系为重

2. 实践派：重实践，重个人感悟，以思想体系为重

从对 DDD 这几年的关注和学习，我把它分成四个部分：

1. 关于结构理论：DDD 是用来进行战术建模与战略建模的

2. 关于过程理论：DDD 是用来指导系统重构与软件工程的

3. 关于语言理论：DDD 是建立关于业务模型的统一语言的

4. 关于建模理论：DDD 是用来指导模型驱动的领域建模的

领域驱动设计在架构设计中的核心思想是将业务领域置于关注的焦点，通过领域模型的建立和应用，实现软件系统与实际业务的密切结合。这种思想的应用使得架构更加灵活，更易于理解和维护。

六、COLA：整洁面向对象分层架构

COLA 架构，即整洁面向对象分层架构，Clean Object-oriented and Layered Architecture，COLA，是一种旨在在架构层面控制软件复杂度的面向对象分层架构。该架构思想不仅提供了理论指导，还包含了具体实施的框架和工具，以确保整个软件系统保持清晰、可维护和可扩展。

核心特点

四层架构

COLA 架构采用四层架构，将系统划分为不同的层次，以便更好地组织和管理系统的组件。

表示层

Presentation Layer

1. 负责处理用户界面和用户输入，呈现数据给用户

2. 包括页面、控制器等组件

应用层

Application Layer

1. 包含应用的核心业务逻辑，协调领域服务的调用

2. 不包含具体业务规则，主要用于编排业务流程

领域层

Domain Layer

1. 包括领域模型、实体、值对象、聚合等，体现了系统的业务核心

2. 包含具体的业务规则和业务逻辑

基础设施层

Infrastructure Layer

1. 处理与外部系统的通信、数据库访问等技术实现

2. 保持与具体技术的解耦，确保系统的灵活性

规范设计

• 组件规范

规定系统中组件的职责和行为，确保组件的设计符合整体架构

• 包规范

定义不同包的职责范围，确保包的划分清晰，避免功能交叉

• 命名规范

统一命名规范，提高代码的可读性，降低团队协作的沟通成本

实施框架和工具

COLA 架构不仅是一种理论指导，还提供了具体实施的框架和工具，以降低实际项目的开发难度和风险。

1. 框架：提供了一套基础框架，包括四层架构的基本结构、组件之间的通信机制等

2. 工具：包括代码生成工具、规范检查工具等，帮助团队在开发过程中快速实现和遵循 COLA 架构

优势

1. 清晰的层次架构：COLA 架构通过四层清晰的层次结构，使系统组织有序，易于理解和维护

2. 规范化设计：采用规范设计，确保团队对系统有一致的认知，提高协作效率

3. 可维护性和可扩展性：通过分层架构和规范设计，使系统更易于维护，并具备良好的可扩展性

4. 降低复杂度：通过控制软件复杂度，使开发团队更加专注于业务逻辑，而不是底层技术的实现

指导原则

COLA 架构的指导原则包括四层架构的划分、规范化设计和实施框架工具的使用，确保整个团队在软件开发过程中能够始终遵循一致的设计理念，提高项目的整体质量。

在 COLA 架构的引导下，开发团队能够更好地应对软件复杂性，确保系统具备良好的可维护性和可扩展性。

七、TOGAF

TOGAF（The Open Group Architecture Framework）是一种通用的企业架构开发框架，由 The Open Group 推出，它提供了一种综合性的方法，帮助企业定义和改进其 IT 战略、规划和实施过程。

概述

TOGAF 的目标是通过定义清晰的技术路线图来改进企业的整体运营效果。包括四个关键部分：

1. 企业架构开发方法论 (Architecture Development Methodology, ADM)：用于描述如何开发有效的企业架构；提供了一套结构化的方法，帮助组织在不同层面上理解、规划和实施其架构

2. ADM 的指导说明：提供关于如何有效使用 ADM 的详细指导，以确保架构的一致性和质量

3. 参考模型：作为一个标准，提供了共享的基础架构，以促进企业架构的一致性和互操作性

4. 辅助资源：包括框架、目录、指南和支持工具等，为组织提供实施 TOGAF 的辅助资源

ADM 步骤

TOGAF 的 ADM 提供了一套详细的步骤，以引导企业架构的开发和实施：

1. 初步调查：确定架构开发的范围和目标，建立团队，制定计划

2. 商务需求分析：收集并分析业务需求，识别与业务目标相关的关键问题

3. 架构愿景与发展计划：制定架构愿景，确定实现愿景的计划和阶段

4. 架构内容开发：开发与架构愿景一致的详细架构内容，包括业务、数据、应用和技术层面

5. 架构交付物管理：管理和维护架构开发过程中产生的各种文档和交付物

6. 解决方案评估：评估候选解决方案，选择最佳方案以实现架构愿景

7. 实施与变更管理：制定实施计划，监督实施过程，管理变更并确保项目成功

优势和价值

1. 综合性方法：TOGAF 提供了一种综合性的企业架构开发方法，使组织能够在不同层面上协调和管理其架构

2. 标准化和一致性：使用 TOGAF 可以促进标准化和一致性，确保整个企业在架构设计和实施方面保持一致

3. 规划和管理：ADM 提供了一套清晰的步骤，帮助组织规划、管理和实施其架构，确保项目按计划进行

4. 支持工具和资源：TOGAF 提供了一系列辅助资源和支持工具，帮助组织更轻松地采用和实施该架构

指导原则

TOGAF 的指导原则包括使用 ADM 进行系统化和结构化的架构开发，依赖于参考模型和辅助资源，以及遵循详细的指导说明。通过遵循这些指导原则，组织可以更好地实现其企业架构的目标，提高整体运营效果。

八、DODAF

DODAF（Department of Defense Architecture Framework）是由美国国防部于2003年推出的系统架构框架，旨在建立一套系统架构开发、管理、改进和实施的标准。

概述

DODAF 的主要目的是提供一种标准的系统架构框架，以支持美国国防部及其他组织进行系统分析、系统集成和项目管理。它主要由五个层次组成：

1. 运营视图：关注业务流程和战术层面的分析，强调组织的战略目标和业务流程

2. 系统视图：关注系统和技术层面的分析，强调系统之间的相互关系和技术实现

3. 技术标准视图：关注技术标准和规范，强调系统的技术特性和标准遵循

4. 项目视图：关注项目管理和执行层面的分析，强调项目的计划、进度和资源分配

5. 数据视图：关注数据流和信息层面的分析，强调数据的收集、存储和传递

DODAF 强调架构的可视化和完整性，并允许不同的参与者和角色参与架构的开发过程。

特征和要求

每个视图都有自己一系列的特征和要求，以确保架构的全面性和一致性。最重要的特征包括：

1. 架构框架：提供了整体的结构，定义了视图之间的关系和组织的总体构架

2. 业务流程：在运营视图中强调了业务流程，有助于理解组织的战略目标和核心业务

应用范围

DODAF 的应用范围涵盖多个方面，包括系统分析、系统集成和项目管理。其广泛应用的领域包括：

1. 系统分析：提供了多个视图，以全面了解系统的各个层面，促使系统分析更加全面和深入

2. 系统集成：强调系统之间的关系和技术实现，有助于有效进行系统集成

3. 项目管理：在项目视图中关注项目的计划、进度和资源分配，支持项目管理和执行

优势和价值

1. 标准框架：DODAF 提供了一个标准框架，为组织提供了一致性的系统架构开发方法

2. 可视化和完整性：强调架构的可视化和完整性，有助于组织更好地理解和管理其系统

3. 战略和战术层面：同时关注战略和战术层面的分析，使得架构能够在不同层面上提供支持

4. 多角色参与：允许不同的参与者和角色参与架构的开发过程，促进了多方面的协作

指导原则

DODAF 的指导原则包括使用不同的视图来覆盖系统的不同层面，确保架构的一致性和全面性。通过遵循这些指导原则，组织可以更好地应用 DODAF 框架，提高系统架构的质量和可管理性。

结束语

在软件架构的领域中，我们介绍了多种经典架构模式，每一种都为解决特定问题和满足不同需求提供了独特的视角和解决方案，旨在帮助大家理解不同架构设计风格的适用场景，为未来的项目开发提供丰富的选择。

从经典的 MVC 到颠覆性的 CQRS，从灵活的六边形到深入的 DDD，从洋葱到可扩展的 COLA，从基础的模式到复杂的企业级架构框架，每一种都代表了一种独特的思考方式和技术实践。

无论您是在简单的 Web 应用程序还是复杂的分布式系统工作，理解并熟练运用这些架构都将有助于构建出更健壮、可维护且适应未来需求变化的软件。

记住，架构设计没有银弹，选择最适合您的项目和团队的架构才是最为关键的，让我们通过不断学习和实践，积累更丰富的架构经验，不断提升自己的架构设计水平，推动团队和组织朝着更稳健、可维护、可扩展的方向发展，同时在这个实践过程中不断提升我们的架构技能。