在一个变化迅速、不确定性日益增加的世界中，组织必须不断做出适应和演进，以此来保持竞争力，并在市场上脱颖而出。设计适应性听起来容易做起来难。如何设计和构建能够在不断变化的环境中演进和蓬勃发展的系统？我的建议是采用一种整体性的方法，能够结合与业务战略、软件架构和团队组织相关的观点。

本文从高层次的角度介绍了如何结合 Wardley Mapping、领域驱动设计（DDD）和团队拓扑来设计和构建针对快速变化流而优化的自适应协作性技术系统。

本文重点介绍了一个在线教学遗留系统的演进示例，通过创建一个 Wardley Map 来可视化其业务环境，并演示了如何将 Wardley Map 与 DDD 相连接来发现其核心领域并将单体大泥球分解为模块化的组件（有界上下文）。此外，本文还提到了如何以先前创建的 Wardley Map 为基础来确定适合团队拓扑的边界。

一种优化组织的系统性方法

大多数试图改变或优化系统的方法通常都是针对局部进行的改进，它们倾向于专注对系统各个部分进行局部优化。

Russell Ackoff 博士（系统性思维先驱之一）认为，对系统各个部分进行局部优化不会改善整体性能。他指出：“一个系统不仅仅是其各部分之和，而是它们相互作用的产物。部件之间的配合方式决定了一个系统的性能——而不是它们单独运行时的性能。”此外，在构建系统时，我们需要考虑有效性（构建出正确的事物）和效率（以正确的方式构建出事物）。

图 1——构建系统所面临的普遍性挑战

构建可以解决有效性相关问题（例如，解决方案与用户需求的一致性）的东西。为用户创造有意义的价值对组织取得成功来说至关重要。这涉及理解问题并分享对问题共同的见解。在构建事物时关注效率，特别是工程实践的效率。效率是关于利用率的，不仅要能够产生价值，而且要能够很好地交付价值。这关系到我们能够多快地交付变更，能够多快、多容易地让变更生效并适应新情况。构建正确的事物与正确地构建事物缺一不可。但正如 Russell Ackoff 博士所指出的那样，“把错误的事情做对了并不会比把正确的事情做错了好。”

设计具有适应性的组织

为了构建能够在不断变化的环境中进行演进和蓬勃发展的自适应协作性技术系统——兼顾有效性和效率，用正确的方式构建出正确的事物并考虑整体性——我们需要一种结合了各种观点的整体性方法。它要求我们理解组织运营和竞争的业务环境，包括影响环境的外部力量，以便设计出有效的业务战略。它要求我们获得领域知识并理解业务领域，以便构建与业务需求和战略紧密对齐的系统。它不仅要求对齐技术解决方案，还要求对齐团队，并让它们的交互与我们构建的系统和计划的战略保持同步演进。

图 2——Wardley Mapping、领域驱动设计和团队拓扑相结合

换句话说：一种设计、构建和演进针对快速变化流而优化的自适应协作性技术系统的方法可能是将 Wardley Mapping、领域驱动设计（DDD）和团队拓扑这些点连接起来。

使用 Wardley Map 来可视化环境

要理解组织运营和竞争所处的业务环境，创建 Wardley Map 是一个很好的起点。Wardley Map 是 Wardley Mapping 的一部分——Simon Wardley 发明的一种商业战略框架。Wardley Map 可以对环境和价值链的演变进行可视化。它提供了一种结构化的方式来讨论环境，并帮助我们识别出组织可以创新、提高效率或外包以获得竞争优势的领域。

在创建 Wardley Map 时，我们通常从确定用户和用户需求开始——它们是 Map 的锚点。用户可以是客户、商业伙伴、股东、内部用户，等等。在一个在线教学解决方案的示例中，如图 3 所示，教师和学生就是用户。教师可以创建课程内容、做出课堂计划并在学生学习期间提供支持。学生的需求是学习课程、发起和接受帮助，以及接收评估反馈。两者都需要注册和登录。一系列向用户传递价值的组件直接或间接地满足了这些用户需求。教师和学生直接与在线教学组件发生交互，这个组件对用户是可见的，位于价值链的顶部。此时，在线教学组件是一个单体大泥球，如果我们从 DDD 的视角来看它，我们可以将其分解为更小的部分。

图 3——Wardley Map 的价值链（Y 轴）

在线教学组件依赖于其他组件，例如基础设施组件（数据存储、搜索引擎、消息代理 SMTP 服务器、运行在虚拟机组件之上的计算平台组件）。它们对用户不太可见，并处于价值链的更下方的位置。

价值链的组件通常被映射到各个演化阶段，例如创世纪、定制构建、产品（+租赁）（现成产品或开源解决方案）和商品（+实用组件）。每个演化阶段都具有不同的特征，如图 4 所示。Wardley Map 左侧光谱位置的组件比光谱右侧的组件变化得更加频繁。在左边，我们面临的是高度不确定性和未被定义、未被充分理解的市场。而在右侧光谱上，组件变得更加稳定、知名、广泛和标准化，市场也变得明确和成熟。

图 4——各个演变阶段的特征

我们可以利用这些特征来确定价值链组件或在线教学解决方案的演化阶段，如图 5 所示。在线教学组件反映了一个经常变化并能够提供竞争优势的不稳定组件，它应该进入到定制构建演化阶段。对于基础设施组件，如搜索引擎、数据存储、消息代理等，我们目前正在使用开源解决方案，而虚拟机组件由服务器托管提供商作为现成产品提供，所以当前状态的基础设施组件进入了产品（+租赁）演化阶段。

图 5——价值链组件与各个演化阶段映射（X 轴）

这个 Wardley Map 代表了第一次迭代。Wardley Map 并不会精确完美地表示环境，它只会提供有用的抽象和近似。与一群人一起创建 Wardley Map 会带来相当大的价值，它可以促进参与者对环境的共同理解。与他人分享 Wardley Map 有助于对自己的假设提出挑战。这些对话有助于共同讨论和理解当前和未来的环境。我们可以将当前环境的 Wardley Map 作为未来讨论演化系统的基础。

Wardley Map 只是 Wardley Mapping 的一部分。一般来说，Wardley Mapping 有助于根据情境意识和战略周期活动设计和演化有效的商业战略。图 6 描绘的战略周期包含了“变化的表示，以及我们如何应对它”。

图 6——Wardley Mapping 的战略周期

战略周期包括五个部分，从目标（Purpose，描述了组织存在的原因和动机）开始。Landscape 代表组织运营的竞争环境——通过 Wardley Map 进行了可视化，如前所述。

为了预测变化并识别出创新领域，我们需要了解影响环境的外部力量——这里被描述为气候（Climate）模式。例如，有一种气候模式是环境不是静止的，而是动态的：一切都通过需求和供应的竞争来推动演化。云托管服务就反映了这种气候模式。几十年前不存在的东西通过创世纪、定制构建阶段成为产品，然后进一步成为商品。

为了能够快速响应变化并优雅地吸收变化，Wardley Mapping 建议应用与上下文无关的教义（Doctrine）原则。教义原则是每个行业都可以应用的普遍原则，与上下文无关。例如，教义原则“每个演化阶段采用适当的方法”建议在创世纪或定制构建演化阶段通过敏捷方法来构建组件，对产品（+租赁）阶段的组件使用或购买现成产品或开源软件（使用精益方法），或将商品阶段的组件外包给供应商（使用六西格玛方法）。在本文后面，我们将讨论如何将这一教义原则与 DDD 子领域类型相结合。

领导力是 Wardley Mapping 战略周期的最后一个部分，主要是关于在考虑环境、气候和教义的情况下选择什么战略。Simon Wardley 提供了一系列游戏玩法，它们描述了组织在创建新市场、在既定市场参与竞争、保护现有市场地位和退出衰落市场方面可以采取的战略行动。

从团队角度看流程优化的要求

为了从团队角度优化快速的变更流程，我们需要避免组建孤岛功能团队。相反，我们需要致力于组建自主、跨职能的团队，他们负责设计、开发、测试、部署和运营他们负责的系统。我们需要避免繁琐的交接工作，这样在实现和发布变更时就不需要将工作交接给另一个团队。我们需要将小型、长寿命的团队作为常态。团队需要有他们所负责的系统或子系统的所有权。他们需要承担端到端责任，这样才能实现快速流动。我们需要降低团队的认知负担。如果团队的认知负担出现超载，就会成为导致质量问题和延迟交付的瓶颈。虽然团队内部的沟通是必需的，但我们也需要限制团队之间持续的高带宽沟通，以实现快速的流动（见图 7）。

图 7——从团队角度看流程优化的要求

团队拓扑基础

在这方面，团队拓扑能够帮到我们，它们有明确定义的团队类型（见图 8）和明交互模式（见图 9）。流对齐团队是指自主、跨职能且与专注于快速变化的持续工作流对齐团队。为了能够进行稳定的功能交付并专注于快速变化流，流对齐团队需要其他团队的支持，例如平台团队。平台团队为流对齐团队提供支持，并负责提供流对齐团队可以轻松使用的自助平台。平台团队为他们所负责的平台提供内部自助服务和工具。赋能团队可以被认为是内部教练，帮助流对齐团队识别和获取他们缺失的能力。复杂子系统团队——作为可选团队类型——可以在需要专业知识的、特别复杂的子系统上为流对齐对齐团队提供支持。

图 8——团队拓扑的四种团队类型

所有这些团队类型都旨在增加自主性并减少流对齐团队的认知负担，最终实现快速变化流。

光是拥有上述这些团队类型还不足以奏效，要提升组织效能，如何让这些团队相互交互以及何时做出改变和演化也非常重要。

图 9 画出了团队拓扑建议的交互模式。团队在有限的时间内进行紧密的合作，这非常适合用于进行快速发现和创新，例如探索新技术。协作的时间应该是短暂的。当一个团队需要使用代码库、组件、API 或平台时，可以采用“X 即服务”这种方式，这些东西可以由另一个团队按照“即服务”的方式来提供。这在需要进行可预测交付的场景中表现最好。当一个团队能从另一个团队的帮助中获得收益时，促进作用才会见效。这种交互模式是给团队赋能的典型模式。

图 9——团队拓扑的三种交互模式

流对齐团队、平台团队、赋能团队和可选的复杂子系统团队及其协作、X 即服务和促进等交互模式提升了组织效能。

识别变化流

要应用团队拓扑并优化流程系统，我们可以将之前创建的 Wardley Map 作为基础。要优化快速变化流系统，我们需要知道系统中最重要的变化发生在哪里——即变化流。变化流的类型因任务、角色、活动、地理位置和客户细分导向的流类型而不同。在我们的示例中，我们关注的是 Wardley Map 用户需求所代表的活动流。创建课程内容、规划课程等用户需求——如图 10 所示——属于活动导向流类型，它们是优化流程时需要着重关注的点。

图 10——将用户需求作为活动导向的变化流

划分问题域并找出核心域

用户和用户需求不仅是 Wardley Map 的锚点，也可以表示问题域。在这里，我们可以引入 DDD。DDD 可以帮助我们获取与问题域相关的领域知识，并将问题域划分为更小的部分——子域。但并非所有子域都是同等重要——有些在业务上比其他子域更有价值。我们有不同类型的子域，如图 11 所示。

图 11——DDD 的子域类型

核心域是问题域最重要的部分，是我们必须进行最多战略性投入并在内部为其构建软件的子域。创建课程内容、规划课程、提供学习支持和学习课程等用户需求属于核心域，它们会带来高级别的差异化。购买或外包这个子域的解决方案会影响企业取得成功，因此我们必须在内部为核心域构建软件。

学生的学习进度评估并不是很重要，但它为教师体验提供支持，对组织取得成功来说是必要的。这些用户需求属于支持子域——见图 11。支持子域有助于支持核心域，虽然它们不提供竞争优势，但对组织取得成功来说是必要的，并且在其他竞争对手的解决方案中也普遍存在。如果可能，我们应该购买现成产品或使用开源软件解决方案来支持子域。如果不可能，并且必须为子域定制软件，我们也不应该在系统的这部分投入过多。

登录和注册属于通用子域的用户需求。通用子域是许多业务系统都拥有的子域，如身份验证和注册，它们不是核心，也不提供竞争优势，但又不能没有它们。这些问题通常已经有人解决过了，所以可以购买现成产品或使用开源解决方案，或将通用子域的解决方案外包给供应商。

子域类型可以帮助我们确定战略投入、定制构建、购买和外包决策的优先级。

有界上下文作为团队边界

子域的解决方案目前都混杂在一个紧密耦合的单体中，模型混乱，没有明确的边界。为了对变化做出响应，在线教学示例的架构需要进行具有高功能内聚性和松散耦合性的模块化。我们需要将在线教学组件分解为模块化组件，这个时候需要使用 DDD 的有界上下文。有界上下文对相关业务行为进行分组，并反映出域模型可以应用的边界。有界上下文不仅有助于拆分系统，也可以作为有效的所有权边界。设计有界上下文和域模型需要领域专家和开发团队之间进行紧密的合作，以获得对领域的共同理解。设计有界上下文和域模型可以使用多种互补的技术，如 EventStorming、Domain Storytelling 等。

图 12 画出了在线教学示例的有界上下文。内容创建、课程管理、课程学习和学习支持的有界上下文与核心域相关的用户需求相匹配。它们在战略上很重要，需要最多的开发工作。它们处于定制构建演化阶段，并需要在内部构建。

学生学习进度评估和通知处理的有界上下文属于支持子域，市场上可能已经有相应的解决方案。不过团队认为需要更高水平的专业化，所以要在内部构建它们，但开发投入不应过高。

身份和访问管理有界上下文属于通用子域，市场上已经存在几种解决方案，应该处于产品（+租赁）或商品（+实用组件）演化阶段。

图 12——在线教学示例的有界上下文

有界上下文不仅有助于拆分系统，而且也可以作为有效的所有权边界，可以形成意图、可控和自主的单元。有界上下文为流对齐团队指出了合适的团队边界，如图 13 所示。

图 13——有界上下文作为对齐团队的团队边界

识别可为变化流提供支持的服务

为了能够专注于快速变化流，流对齐团队需要其他团队的支持，他们依赖其他团队的支持来完成工作。这就需要识别出可靠变化流所需的服务，这些服务可以形成自助平台，提供易于使用的“X 即服务”。一般来说，平台可以有不同的抽象层次。从高层次上看，平台可以是设计系统、数据平台等。从较低的层次看，平台可以抽象掉基础设施或横切能力。在我们的在线教学示例中，位于产品（+租赁）和商品（+实用组件）演化阶段的 Wardley Map 中与基础设施相关的组件可以成为平台服务，由平台团队负责提供（见图 14）。

图 14——为可靠变化流提供支持的服务

可能的团队组合

按照前面考虑的事项，这个团队组合可以作为初稿，如图 15 所示。一般来说，组织中的大多数团队都将是具有端到端责任的跨职能、自主的团队。为了实现清晰的责任边界，一个有界上下文只能由一个团队拥有，但一个团队可以拥有多个有界上下文。处于定制构建演化阶段的四个与核心域相关的有界上下文将在三个流对齐团队之间进行分配。我们示例中支持和通用子域相关的有界上下文将由另一个流对齐团队负责，基础设施组件将由一个或多个平台团队负责。

图 15——一种可能的团队组合的初稿

平台团队可以提供各种平台来满足流对齐团队的需求，这可以在不同的 Wardley Map 中可视化，其中流对齐团队成为内部用户，然后我们继续找出和弥补能力差距，这个时候赋能团队就可以发挥作用了。

从小处做起

在应用和结合使用 Wardley Mapping、领域驱动设计和团队拓扑之前，你不需要详细了解它们。你可以从对上下文最有用的部分开始。你可以先和小组在一起创建一个 Wardley Map，形成对竞争环境的共同理解。在与他人创建和分享 Wardley Map 并挑战自己的假设时，就已经产生了重大价值。你可以将 Wardley Map 作为一种结构化的指导和继续对话的方式，例如，识别合适的变化流和团队边界，如本文所示。

你也可以考虑从你的团队开始，分析他们当前的认知负担和交付瓶颈。他们是否在存在重复的交接，是否在进行高水平的沟通和协调，是否存在阻塞依赖，是否缺乏所有权边界，是否存在团队认知负担过高等问题？这些对话可能有助于流对齐和识别出合适的团队边界、分解系统，等等。

或者，你也可以从你当前的软件架构开始，评估它对变化的响应能力，例如，分析哪些部分与特定变化耦合在一起以及这些部分是如何耦合在一起的。这可能会将对话引向识别适合模块化的边界，而 DDD 可以通过子域和有界上下文在这方面提供帮助。每一个起点的路径到了某个时候会相交，形成了流动架构。这只是设计和构建自适应协作性技术系统的一种方法。此外，你还可以用其他技术和框架来补充优化你的系统，例如价值流映射、独立服务启发式、Cynefin，等等。

作者简介：

Susanne Kaiser 是德国汉堡的一位独立技术顾问，协助企业建立协作性技术系统。她热衷于将 Wardley Mapping、领域驱动设计和团队拓扑连接起来，作为一种整体性方法来设计和构建适应快速变化的系统。Susanne 之前是一家初创公司的首席技术官，拥有计算机科学背景和软件开发和架构方面的经验。她是“daptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow”（Addison-Wesley，2023）一书的作者。

查看英文：

https://www.infoq.com/articles/adaptive-socio-technical-systems-flow/

相关阅读：

持续集成的关键：产品反馈驱动实践

领域驱动探索：开启架构现代化转型之路