一文搞懂企业架构与DDD的融合

内容转载自：架构师汤师爷

今天聊聊企业架构与DDD如何进行融合。

一、企业架构TOGAF

什么是企业架构TOGAF？

TOGAF（The Open Group Architecture Framework）是一个广泛采用的企业架构（Enterprise Architecture, EA）框架，由开放组（The Open Group）开发和维护。

它为组织设计、规划、实施和治理企业信息架构提供了系统化的方法和工具。TOGAF旨在帮助企业通过高效的架构管理，实现业务目标、优化资源利用和增强灵活性。

TOGAF发展历程

如图展示了从1970年代至2012，企业架构框架和相关标准的演进历程，其中包括：

• C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance)
• TAFIM (Technical Architecture Framework for Information Management)
• Zachman Framework
• TOGAF (The Open Group Architecture Framework)
• FEAF (Federal Enterprise Architecture Framework)
• DoDAF (Department of Defense Architecture Framework)以及ArchiMate

在此历程中，美国各组织和政府部门陆续制定并优化了各自的企业架构方法论和标准，携手推动了企业架构领域的蓬勃发展。

1970年启动的C4ISR计划为军事和政府架构提供了架构理论基础。

1986年开始研发的TAFIM和1987年提出的Zachman框架，标志着企业架构实践开始走向系统化。

1993年，The Open Group成立并着手制定系统标准，随后在1995年发布TOGAF 1.0，为商业领域提供了通用的企业架构开发框架。

1996年，美国联邦政府颁布了里程碑式的克林格·科恩法案，要求政府机构（特别是国防部和财政部）采用企业架构理论构建IT系统。这项法案为政府机构的数字化转型注入强劲动力，显著提升了其信息化水平。

1997年，C4ISR升级为AF 2.0版本。1999年，联邦企业架构FEAF问世，为政府跨部门整合提供了方法论支持。

进入2000年，TOGAF相继发布7.0版本（2001年）和8.0版本（2002年），持续完善其架构开发方法。同期，政府部门推出DoDAF（2003年发布1.0版）和FEA相关方法（2002年起持续更新），两者形成了良性互动。

2006至2008年间，FEA-PMO陆续发布FTF、EAAF3.0等成果，DoDAF也更新至1.5版。

2009年，The Open Group发布TOGAF 9，为企业架构领域带来更系统、更灵活的方法体系。同期，DoDAF在2010年更新至2.02版。

2011年，TOGAF 9.1的发布进一步优化了框架内容，使架构师能更顺畅地应用这一方法论。

为满足日益增长的架构可视化和建模需求，The Open Group于2008年接管ArchiMate的研发工作，并在2012年发布ArchiMate 2.0，为企业架构的表达和沟通提供了统一的建模语言。

在2022年，TOGAF正式发布了10版本，这是一次重大更新。TOGAF 10在保持核心框架稳定的同时，增强了灵活性和适应性，更好地支持数字化转型和敏捷开发等现代企业需求。

TOGAF通过吸收政府机构在企业架构实践中积累的丰富经验，不断完善和沉淀，最终发展成为一套通用且系统化的企业架构方法论。

这套方法论不仅适用于政府机构，还能广泛应用于各类企业和组织。目前，福布斯前50强企业中有80%采用TOGAF理论，美国500强企业中有60%使用这一方法论来优化和改进其IT架构。

这些数据有力地证明了TOGAF在企业架构领域的权威性和实用价值，同时也凸显了企业架构理论在现代组织管理和IT治理中的重要地位。

在TOGAF理论中，有四种核心视图：业务架构、应用架构、数据架构和技术架构。

这四个架构视图构成了企业整体架构的核心。虽然各视图关注点不同，但它们相互联系、相互支撑，共同构建了完整的企业架构体系。如图2-3所示。

业务架构

业务架构定义了企业如何将其业务战略转化为结构化的、全面的、多维度的抽象模型。这些模型包括价值流、业务能力、业务流程、业务对象和组织架构，同时描述了它们与企业战略、产品、策略、项目执行以及利益相关者之间的关系。

应用架构

应用架构描述了企业内应用系统的结构、行为和相互关系，以及这些系统如何支持业务流程。它既关注单个应用的架构设计，也注重应用系统间的协作方式，确保所有系统能够协同运作，有效支撑企业目标。

数据架构

数据架构明确定义企业的数据管理方式，包括数据的收集、存储、管理和使用。它包括数据模型设计、数据库技术选型，以及数据治理机制的建立与实施。

技术架构

技术架构描述了支撑企业业务、数据和应用服务所需的IT基础设施和技术组件结构，包括硬件设施、软件包、网络系统、技术中间件、通信设备和计算资源等。

二、企业架构与DDD融合

在前文中，我们已经了解了TOGAF企业架构的四大视图，它们共同构成了一个完整的企业架构框架。

接下来，我们将深入探讨领域驱动设计（DDD）这一重要方法论，以及它如何与企业架构协同工作来解决复杂的业务问题。

通过了解DDD的核心概念和应用方式，我们将看到它如何帮助组织更有效地实现从业务战略到技术实现的转化。

1. DDD是什么

大多数人初次接触领域驱动设计（DDD）时，通常会阅读Eric Evans的《领域驱动设计》。这本书被誉为DDD的”圣经”，但许多读者看完后往往感到困惑，觉得内容深奥难懂。

DDD旨在实现软件系统与业务的紧密对接，提高开发效率和质量，同时更好地应对复杂性和变化。它将业务置于核心地位，通过深入把握领域知识并建立有效的领域模型，来指导软件设计和开发过程。

具体而言，DDD的核心理论包括：

• 分治思想：DDD应对复杂性的核心理念是”分而治之”。它将复杂的业务领域划分为较小的子域，并在每个子域中明确上下文边界和核心实体等要素。通过这种系统化的分解、分类和推导过程，最终形成最优解决方案。
• 领域建模：DDD的核心在于将业务流程抽象化，通过定义领域实体、领域服务和领域事件等要素来满足业务需求。作为贯穿整个软件生命周期的方法论，领域模型让开发人员、产品经理和架构师能够基于统一的模型进行设计和讨论，确保项目始终保持正确方向。
• 架构分层：DDD采用清晰的分层架构，将应用程序分为用户接口层、应用层、领域层和基础设施层四个主要层次。每一层都具有明确的职责和功能定位。这种分层架构使业务领域的结构更加清晰、有序。
• 事件驱动：领域事件是一种跨领域的交互机制，负责在不同模块之间传递信息。通过事件的发布与订阅机制，不仅使领域模型更加简洁，还实现了系统间的低耦合。

2. DDD与架构视图

在4大架构视图（业务架构、应用架构、数据架构、技术架构）和DDD的落地过程中，存在2个问题：

1. 1. 在业务领域划分环节，DDD 未提供明确的领域划分指导，如何进行合理的领域划分？
2. 2. 如何基于业务架构合理划分应用系统结构和抽象数据模型？

业务架构与DDD方法论的融合能有效解决这两个问题。

端到端的业务流程包含多个业务场景，每个场景都需要依赖不同的业务能力。通过对业务能力进行分层抽象，我们可以识别出各个层次的业务能力，这为领域和子域的划分提供了重要依据。

在应用架构设计阶段，需要对应用系统结构进行划分。应用是一个可独立发布和部署的单元，可提供一个或多个应用服务。在这一过程中，DDD中的限界上下文为划分应用结构提供了有效依据：

• 当业务复杂度高、用户规模大且团队规模大时，应用系统需要拆分为微服务，以实现独立部署和维护。这种情况下，通常一个限界上下文对应一个微服务。
• 相比之下，当应用系统面向企业内部用户时，由于用户规模较小，通常不需要分布式架构。这类应用宜采用较大颗粒度划分，将多个相关的限界上下文整合在一个应用中，以减少系统调用并降低部署复杂性。

在数据模型设计过程中，DDD的核心概念为数据建模提供了重要指导：

• 聚合根定义了数据访问的边界，作为一组相关对象的统一入口。
• 领域实体是具有唯一标识的业务对象，体现了核心业务概念。
• 值对象则是通过其属性来定义的对象，它不需要概念上的唯一标识。

这些模型元素共同构成了一个丰富的业务概念框架，指导数据模型的设计，确保数据模型能准确反映业务领域的复杂性和内在逻辑。通过将这些概念应用到数据建模中，我们可以创建出更贴合业务需求、结构清晰、易于维护的数据模型。

3. DDD带来的价值

DDD为企业带来多方面价值，包括提升团队协作效率、沉淀业务能力和优化技术实现。让我们从以下关键方面深入了解DDD在实践中的具体价值与优势：

1、统一语言

业务、产品、设计和技术团队使用统一的业务术语进行沟通。无论是日常交流、设计讨论、文档编写、图表绘制还是代码开发，都采用同一套标准化语言，大幅提升了工作效率。

2、团队协作高效

通过系统化地识别和分类需求，将其划分为清晰的领域、子域和限界上下文，能有效指导团队分工协作，避免职责混乱。这种划分可以防止任务错配，例如将原本属于技术团队A的任务，错误分配给团队B。也能避免两个团队重复开发同一功能，造成资源浪费。

3、领域能力沉淀

业务能力的可复用性是衡量软件架构设计质量的关键指标。通过建立业务知识与模型之间的统一映射关系，并持续验证和优化这些模型，我们能确保它们准确反映当前业务状况。这种方式让业务知识能够通过模型得到有效传承，让团队新成员能够准确理解业务逻辑。

4、业务与技术有效融合

传统开发方式过分注重数据库表结构设计，却忽略了业务模型。DDD则采用相反的策略——先抽象业务领域模型，再据此设计数据库结构。这种方法让业务与技术真正融合，克服了传统开发中只关注数据层和接口层的局限性。

4. DDD的缺点

尽管DDD在构建复杂软件模型方面具有显著优势，但这套方法论也存在一些明显的局限性。

1.学习曲线陡峭

DDD包含了限界上下文、实体、值对象、聚合和领域事件等一系列复杂概念和实践。掌握这些概念需要投入大量时间和精力，对初学者或习惯简单开发模式的团队来说尤其具有挑战性。

2.过度设计的风险

团队在运用DDD概念时，容易陷入过度设计的陷阱。为了完美实现领域模型，可能会构建过于复杂的层次结构和关系，导致”充血模型”泛滥，甚至演变成”高血压模型”。这不仅增加了项目的复杂度，还会显著提高开发和维护成本。

3.实施成本和时间

DDD的正确实施需要投入大量时间和资源进行领域建模，同时要求与业务方保持密切沟通。这种特性在项目初期可能会放慢开发进度，特别是对需要快速交付的短期项目来说，会带来较大压力。

4.不适用于所有项目

DDD主要适用于业务逻辑复杂、需要长期发展和维护的大型软件项目。对于业务简单或生命周期较短的项目，使用DDD反而会带来不必要的复杂性和额外投入，因此并不适合。

5. DDD的核心概念

为DDD的完整设计流程，DDD的核心理念由两个关键部分构成：战略设计和战术设计。

战略设计专注于宏观层面的领域分析和边界划分，而战术设计则着重于微观层面的领域模型实现。

领域和子域

领域指的是特定的业务范围或问题域。在运用DDD解决业务问题时，会将业务领域细分，并将问题限定在特定边界内。在这个边界内，DDD建立领域模型，并通过代码实现这些模型来解决相应的业务问题。这种方法的核心思想是”分而治之”。

领域可以进一步划分为子域，每个子域对应一个更小的问题域或业务范围。DDD本质上是一种处理复杂领域的设计方法，它通过持续细分将复杂的业务简化，使其更易理解和实现。

这种方法类似于公司的组织结构。以一家互联网创业公司为例，它包含产品研发部、市场营销部、客户服务部等部门。领域就像公司的一个大部门，比如产品研发部，负责产品的设计与研发，主导公司的产品方向和策略。

子域则类似于大部门下的小团队。例如，产品研发部门下设有产品团队、前端团队、后端团队和测试团队。每个子域团队专注于具体职能任务，共同支撑上级部门的目标。这种分层确保每个部门、团队和小组都有明确的职责，让公司运作更加有序高效。

同理，在DDD中，通过划分领域和子域，软件研发团队能更好地理解和处理复杂的业务需求。各个层级虽关注不同细节，但通过协作完成整个系统的开发。

核心域、通用域和支撑域

在领域划分过程中，子域可根据其重要性和功能属性分为核心域、通用域和支撑域。

核心域决定产品和公司的核心竞争力，通用域是多个子域共用的功能域，支撑域则负责支持业务运转，但既不直接影响核心竞争力，也不包含通用功能。

划分这三类域的主要目标是聚焦关键事项。通过这种划分，公司能够清晰区分不同子域的重要性，从而更有效地分配资源和关注度，在激烈的市场竞争中保持优势。

以电商领域为例，主要子域包括商品、订单、用户、支付、物流、客服和数据分析。

在电商领域中，核心域直接关系到业务的核心价值和主要收入，主要包括：

• 商品子域：负责管理商品信息，包括展示、分类、搜索和推荐等功能，构成电商平台的基础。
• 订单子域：负责订单的创建、修改、查询和状态管理等，是交易流程的关键环节。
• 支付子域：负责支付交易处理，包括支付方式管理、状态跟踪和渠道对接等，是完成交易的核心环节。
• 物流子域：负责商品配送管理，包括物流公司对接和配送状态跟踪等，确保商品准确送达消费者。
• 客服子域：提供客户支持服务，包括咨询和投诉处理等，解决用户使用过程中的问题。

通用域支持多个业务领域的运作：

• 用户子域：负责用户信息管理，包括注册、登录和资料编辑等。虽然用户管理在多个系统中都很重要，但在电商系统中主要是支持核心业务流程。

支撑域为核心域提供支持，主要涉及决策分析支撑：

• 数据分析子域：负责业务数据分析，包括用户行为和销售数据分析等，为决策制定和业务优化提供支持。

限界上下文

在DDD中，限界上下文（Bounded Context）是对一个特定业务边界内的概念和规则进行统一管理的范围。它将领域模型的适用范围、业务语言以及规则约束都界定在一个相对独立的“上下文”中，以避免概念在不同业务场景间的混用或冲突。

在一个复杂系统里，不同业务子域可能对同一个名词或实体有各自的含义和处理逻辑。若不加区分，容易出现命名混乱、逻辑冲突等问题。通过划分限界上下文，可以让团队在各自的上下文内部使用统一的“业务语言”，保持模型的一致性与完整性。

在限界上下文之间，通常还需要定义清晰的协作关系和数据交换方式。例如通过上下文映射（Context Map）来确定上下文之间的接口、依赖以及团队之间的协同策略。这样可以最大程度减少跨上下文沟通带来的复杂度，也让每个上下文能独立演进。

例如在电商平台中，“订单”一词在“支付”上下文和“仓储”上下文可能包含不同的信息和规则。支付上下文关注付款状态、交易金额等，仓储上下文关注库存、物流等。把它们划分到不同的限界上下文，可以让每个上下文的“订单”实体都针对自己需要的领域规则进行优化，避免混淆。

实体

实体是具有唯一标识的对象。即使实体的其他属性发生变化，只要其标识（如ID）保持不变，它就仍被视为同一个实体。实体在系统中代表持续存在的业务对象。实体具有以下关键特征：

• 标识性：每个实体都有唯一标识，通常通过ID或编码实现。
• 连续性：实体在其生命周期内可能经历多种状态变化，但标识始终保持不变。
• 区分性：即使两个实体的所有非标识属性完全相同，只要标识不同，它们就是不同的实体。

以电商平台的订单系统为例，每个订单实体都有唯一的订单号。即使订单的属性（如商品、数量）或状态（如已付款、已发货）发生变化，只要订单号相同，它就仍然是同一个订单。

值对象

值对象是描述事物状态或属性的对象，它没有唯一标识，且通常不可变。值对象用于表示对象的某个特征，无需独立身份，仅为更完整地描述实体。值对象的关键特征包括：

• 无标识：值对象没有唯一标识。它们通过属性值定义，通常作为实体的一部分存在。
• 不可变性：一旦创建，值对象的属性就不应被修改。若需改变，应创建新的值对象。
• 替换性：由于没有唯一标识，值对象可被具有相同属性的另一个值对象完全替代。

举例来说，订单中的收货地址（包含省、市、街道和邮编）是值对象，因为它没有独立标识，仅描述了一个地理位置。

同样，订单的支付金额（包括数字和货币单位）也是值对象，因为它只描述了价值的数量，本身不需要独立存在。

聚合与聚合根

在DDD中，聚合是一个核心概念，它帮助开发者管理复杂度，尤其是在处理大量相关对象时。聚合由紧密关联的实体和值对象组成，是修改和保存数据的基本单位。每个聚合都有一个仓库，用于保存其数据。

聚合包含一个聚合根和上下文边界。边界根据业务需求和内聚原则，定义了聚合应包含的实体和值对象。聚合之间保持松耦合，这种设计自然地实现了微服务的高内聚、低耦合特性。

在DDD分层架构中，聚合是领域层的一部分。领域层可包含多个聚合，共同实现核心业务逻辑。实体在聚合内采用充血模型实现业务能力，确保业务逻辑的高内聚。

跨多个实体的业务逻辑通过领域服务实现，而跨多个聚合的业务逻辑则通过应用服务来实现。

聚合根可以类比为部门负责人，既是实体，也是聚合”部门”的管理者。作为实体，它拥有自身的属性和业务行为，执行特定的业务逻辑。作为管理者，它在聚合内部会协调实体和值对象，完成业务逻辑。

而在聚合间的协作中，聚合根充当对外接口人。它通过自身ID关联其他聚合，接收外部请求。访问聚合内其他实体时，必须先经过聚合根，再导航至内部实体，外部对象无法直接访问聚合内的实体。

领域服务

领域服务用于处理实体、值对象或聚合无法独立完成的业务逻辑。它专门封装跨实体或跨聚合的复杂逻辑。领域服务仅包含纯业务逻辑，不直接涉及数据库操作、消息队列等具体技术实现。

需要将领域服务与应用服务区分开来。应用服务位于应用层，主要负责调用外部系统和协调多个领域对象的流程。而领域服务则专注于领域内部的业务规则计算。领域服务具有以下特征：

• 跨聚合或跨实体逻辑：当业务逻辑需要使用多个聚合的数据或操作，适合将其放在独立的领域服务中。
• 聚焦业务逻辑：理想情况下，领域服务应只依赖领域模型中的接口或抽象模型，而不关注具体的数据库、网络调用等基础设施细节。这样可以保持领域逻辑的纯净性和可测试性。

领域事件

在DDD中，领域事件（Domain Event）是一个核心概念。它表示业务领域中发生的重要事件，这些事件由具体业务行为触发，例如用户注册、订单生成或支付完成。领域事件反映了业务流程中的关键状态变更，对流程的进展具有重大影响。

领域事件在软件开发中发挥着关键作用，其重要性主要体现在以下几个方面：

1）微服务解耦

领域事件是微服务架构中实现服务解耦的有效工具。通过将直接调用转换为异步消息传递，它降低了服务间的紧密依赖，提高了系统的灵活性和可维护性。

2）数据一致性保障

在分布式系统中，数据一致性维护是一项重大挑战。领域事件通过记录业务操作，使系统即使在发生故障时也能通过重放事件来恢复状态，从而增强了系统的容错能力。

3）系统可追溯性

领域事件为系统提供了完整的历史变更记录。通过存储和追踪这些事件，我们能够清晰地了解系统状态的演变过程，这对故障排查、系统优化和业务分析都具有重要价值。

4）促进业务理解

作为领域模型的重要组成部分，领域事件反映了业务领域中的关键变化。通过识别和捕获这些事件，开发者能够更深入地理解业务规则和逻辑，同时加强研发人员与业务人员之间的有效沟通与协作。

6. DDD分层架构

DDD分层架构是对传统三层架构的优化升级，形成了四层结构。如图2-6所示，这四层从上到下分别是：用户接口层、应用层、领域层和基础设施层。

1、用户接口层

负责管理系统与用户的交互。它接收用户输入（如表单数据或操作），并将应用层的处理结果通过Web页面或移动应用界面呈现给用户。

2、应用层

应用层处理业务用例和流程相关的操作，理论上不应包含业务规则或逻辑。它位于领域层之上，负责协调多个聚合的服务和领域对象，完成服务的编排与组合。

应用层需保持简洁，开发时应避免在此放置领域层的业务逻辑。若应用层过于复杂，可能导致领域模型失焦，使微服务退化为传统三层架构，致使业务逻辑混乱。

3、领域层

领域层是系统的核心，负责封装业务概念、逻辑和规则。它执行核心业务逻辑，并通过各种校验确保业务的准确性。领域层包含聚合根、实体、值对象和领域服务等领域模型对象。

4、基础设施层

基础设施层为其他层提供技术支持和基础服务，包括数据库、文件系统、消息中间件和缓存等。