Xapo银行去中心化的DDD架构实践分享 - martinfowler

Xapo银行使用领域驱动设计、团队拓扑和架构建议流程三种方式实现企业架构的去中心化：

软件架构在构建软件系统实践中的作用一直备受争议。在大多数组织中，你会发现某种 "架构 "功能，通常打着 "企业架构 "的旗号。这通常是一个中央集权的团队，其目的是为了确保所构建的所有软件都符合行业和公司标准，使用适合问题的模式和技术，针对问题空间进行优化，根据需要进行扩展，并避免任何不必要的重复。

事实上，在任何领域和任何有意义的规模上构建任何有价值的软件时，是必须考虑到所有方面的。

通常情况下，架构职能部门负责所有系统变更的架构设计工作，通常与最终实施解决方案的开发团队隔离开来。
这些设计一旦完成，就会交给开发人员去实施。
几十年来，许多组织都是这样工作的。

那么问题出在哪里呢？让我们列举一些：

集中控制使知识只掌握在架构设计人员的头脑中，而实施团队却不承担同样的责任。
这扼杀了创造性思维和好奇心，以及对运行中的系统做出反应的倾向。
对于实际建造系统的团队来说，架构设计简直就是 "别人的问题"；

因此，创建架构设计的团队可能远离实施的第一线，可能无法认识到与特定领域相关的真正挑战。
当他们的设计在包含生态系统的环境中运行时，他们也无法预见其后果；

这就导致开发人员和架构师之间的反馈回路过长，造成交付延迟，并经常导致架构和设计不充分或不恰当；
最终，架构功能成为瓶颈，因为他们必须管理架构变化，并从整个组织的无数结果中学习，排队时间很长。

如果再加上 2020 年的全球大流行病（以及系统现在越来越分散、不断渐进发展的事实），这些挑战就会成倍增加。越来越多的组织开始采用更远程、更灵活的工作方式。传统的面对面协作论坛已经瓦解，知识只能保留在一小部分人中。对决策背后原理的理解丧失了，集体知识形成了缺口，结果往往是糟糕的软件设计和更多的延误。

当然，这些挑战在大流行病之前就已经存在，但是，我们最近看到的人们工作方式的全面变化，让我们看到了旧的集中式软件架构思维方式的缺陷。

Xapo 一直以分散和完全远程的方式工作，但当大流行病袭来时，他们加倍加强了分散去中心化，但目标是不影响架构质量、对变化的响应能力或概念完整性。

一些历史背景...
Xapo成立于2014年，最初为零售和机构客户提供比特币服务，包括托管钱包、交易、支付和冷存储，成为全球最大、最值得信赖的比特币托管机构。2018 年，Xapo 根据其 "保护您的生命储蓄 "的使命，利用其在直布罗陀的业务，成为一家获得全面许可和监管的银行和 VASP（虚拟资产服务提供商）。这一转变使 Xapo 能够在完全受监管的环境中提供包括美元借记卡在内的传统银行服务以及比特币服务。2020 年，Xapo 获得了银行和 VASP 牌照，并开始筹建新的 Xapo 银行。

随着 Xapo 从电子货币转向全面的银行和 VASP 业务模式，Xapo 现有的大部分软件资产得以重新利用。然而，正如你所预料的那样，在 Xapo 成立后的六年里，技术债务、服务的紧密耦合和低内聚力对交付和变革速度造成了巨大的拖累。变更往往会影响多个团队，并跨越多个功能和子域边界。更严峻的挑战是，Xapo 的员工分布在 40 多个国家，超过 25 个时区！

团队是围绕职能部门（产品、设计、架构、工程、质量保证等）组织的，工作以相当瀑布式的方式流经这些部门。排队和漫长的等待时间很常见，这一点在小型集中式架构团队需要参与、审查和批准所有设计时尤为明显。

经验丰富、才华横溢的工程师们正在创造新颖、高质量的软件--很明显，这里的挑战与他们的技能或努力毫无关系。为了做正确的事情并确保持续的质量，流程和组织已经发展起来，然而，不知不觉中，该系统和相关的控制措施正在减缓进展。Xapo 如何才能创建一个组织和系统，让个人贡献者充分发挥潜力，改善流程，减少摩擦，同时维护甚至改进我们的软件和架构？

最后，有必要指出的是，此前我们曾努力定期召集 Xapo 的集体智慧，以制定架构决策。它被命名为 "雅典娜论坛"（the athenaeum），允许工程师们提出、讨论并决定架构和设计方面的问题。虽然起初有很多人参加，但后来却陷入困境。讨论的时间越来越长，无法得出结论，因此很少做出取得进展所需的决定，即使做出了决定，也会在随后一周的讨论后推翻。

奠定基础
显然，需要采取措施减少开发工作流程中的摩擦。此外，为了减少排队和交接工作，让团队能够独立自主地（尽可能地）开展工作成为成功的关键因素。

Xapo 所做的第一件事就是开始从业务领域而不是从技术功能的角度来考虑我们的软件。努什和她的团队知道，领域驱动设计是最终的发展方向，但她一开始就对软件如何融入广泛的业务子领域（支付、银行卡、银行业务、合规等）进行了粗略的评估，我们非常倚重马修-斯凯尔顿（Matthew Skelton）和曼努埃尔-派斯（Manuel Pais）的团队拓扑工作，以创建真正的跨职能团队。在几个月的时间里，Noush 和她的团队与产品部和运营部的同事合作，将整个交付组织迁移到业务对齐的流对齐团队 (SAT)。

与此同时，Noush 的目标是极大地改善开发人员的体验；以前的集中式运营和严格控制使创建或更改服务、更改配置或在不需要票据的情况下做任何事情都变得令人沮丧和困难。为了加快步伐，Xapo 工程部需要优化我们的流程和工具，以便在整个生命周期内实现团队自治和对服务的完全掌控。Xapo 改变了平台团队的使命，使之与之保持一致，并开始认真重构基础设施和工具，以支持这一目标。

就在这个阶段，Noush 邀请 Thoughtworks 参与其中。让有经验的人参与整个组织的这种转型变革，目的是加速这种变革，同时支持我们的工程和产品人员，帮助他们以安全的方式学习这些新原则。

我们一起为整个工程奠定了基础，确定了我们的核心工程原则--主要重点是构建可优化团队自主性和减少移交的软件--并将 DDD 作为一个关键的组织概念加以社会化。在这一过程中，我们继续开展了从转向 SAT 开始的工作，更详细地思考了我们的界限上下文BC，并将其与团队日益紧密地结合在一起，为我们的路线图提供信息，并逐步改进我们的底层架构。

有了这些基础，我们知道了自己的目标，也大致知道了如何实现目标，但作为一个完全偏远、快速发展、不断变化的组织，如何实现目标是下一个挑战。

工作原理
我们采用的方法在安德鲁的博文中有所阐述："以对话的方式扩展架构实践"。与这种方法的所有实例一样，Xapo 组织的具体情况、我们的员工、我们的软件、我们的业务目标以及我们的文化性质都对事情最终如何运作起到了关键作用。

有三个关键因素值得注意：

1. 首先，Xapo 是一家已经转型的公司，正处于全球规模扩张的早期阶段。
2. 其次，Xapiens 的总部遍布各地。Xapo 确实是一家全球性公司，因此默认的通信模式是异步和书面通信。
3. 第三，全球人才库意味着 Xapiens 都是经验丰富的聪明人，可以提供很多意见和建议。有人指出，这在过去妨碍了决策的速度。

我们最初将重点放在三个关键领域：

• 架构建议流程、
• ADR（架构决策记录）
• AAF

我们一起启动了所有这些核心要素，通过介绍架构建议流程的会议建立了 AAF。我们通过一些回顾性的 ADR 预先铺垫了会议进程。这些回顾性 ADR 内容丰富，涵盖了最近做出的将某些关键服务迁移到第三方供应商的重大决策。这是所有与会者至少会部分感兴趣的内容。

我们为 AAF 精心策划了受邀者名单：所有团队的代表都出席了会议，包括架构、信息安全、基础设施、产品、交付、监管、运营、财务甚至行政人员。确定重点的常设议程也很关键。除了标准的 AAF 活动，即查看峰值，然后在游戏中查看 ADR，我们还增加了以下时段：

• 团队耦合问题（产品和交付在此尤为重要--如上所述，Xapo 在 Thoughtworks 参与时启动了团队拓扑结构调整，以调整流程）、
• 四个关键指标（如《DORA DevOps 状态报告》和《加速》一书[1]所述）、
• 云支出

因此，我们在标准集中增加了一个 ADR 状态："采用 "表示 ADR 已实施并在 prod 中运行。

下面我们将详细介绍这一点。

这里有一些关于 Xapo AAF 一般方面的说明。

作为一家 "异步优先 "的公司，Noush 不断向 Andrew 提出挑战，要求他最大限度地提高实施的异步性。安德鲁最初对此表示反对，因为他看到了对话对所有人的价值，而不仅仅是那些直接参与对话的人。

为什么我们一开始没有将架构原则或技术雷达（甚至是 CFR）包括在内？简短的回答是 "它们并不紧急"。

Xapo 工程已经有了书面原则，但更重要的是，它们已经存在于 Xapien 开发团队的脑海中。

但这并不意味着我们忽视了挑战，以及在提供建议的过程中对这些隐含原则的潜在改进。

后来，随着自我管理开始越来越多地融入日益壮大且日益脱钩的团队中，潜在的有价值的分歧和 "有限制的购买 "变得显而易见，雷达也被引入其中。

在此之前，Xapiens 的技术领域一直非常专注（尤其是对于一家前初创公司而言）：当意识到某样东西是有用的，Xapiens 就会去了解它、评估它，并开始使用它。

ADR 也经历了有趣的演变。利用前面提到的一位 Xapien 架构师的强大信息管理技能，我们迅速从基于维基的 ADR 资源库（Confluence）转向基于票单系统的 ADR 资源库（Jira）。

为什么要这样做？

我们已经提到过，我们强烈希望提高决策、实施和部署的吞吐量。
将 Jira 作为我们的 ADR 主页，让我们能够将 "状态 "字段及其不同值之间的转换转化为一个数据点。
每当打开一个新的 ADR 票据ticket时，我们都会自动生成一个 我们都会自动生成一个时间戳，并将状态设置为 "草稿"。

当涉及到 AAF 时，唯一的要求就是将状态设置为 "建议"，并添加另一个时间戳。
(制作议程也变得更容易了--我们在页面模板中设置了一个 "所有内容都在建议中 "的查询）。

后来转到 "已接受 "时也有时间戳，当我们添加上述 "已通过 "状态时，则表明该决定何时被编码并在 PROD 中运行。

转用该工具后，我们没有从团队那里拿走任何东西--我们仍然有一个票据模板，它使关键的 ADR 部分一目了然，而不会丢失任何富文本元素。当状态发生变化时，我们也不再需要记住更新时间戳。

最重要的是，我们仍然使用开发人员日常使用的工具。最重要的是，我们为自己提供了运行各种查询和绘制各种图表的能力，以便深入了解事情的进展情况。

我们要从这些额外数据中寻找什么？所创建的 ADR 数量是一个有趣的数据点，但关键在于从 "草案 "到 "通过 "所花费的时间，包括总体时间和各个步骤的时间。与 DORA 四个关键指标一样，"（决策）前置时间 "也是流程和系统健康的可靠指标。所有这些数据点都与团队共享，使他们能够逐步改进和自我纠正，并提出诸如 "为什么这个问题在草案/建议/接受中存在了这么长时间？

迁移到 Jira 还有另一个好处：它与 Slack 等通信系统的简单集成更加丰富和集中，与 Xapo 的异步文化相匹配。新的 ADR 可以由 slackbot 自动宣布。状态的变化也可以用同样的方式处理。所有这些都无需人工操作，而且我们还免费获得了透明度。不仅如此，通过将 "实施故事 "与 ADR 票据关联起来，我们还可以开始查看与 ADR 相关的工作及其状态。这对于跨团队的 ADR 尤为有用，例如在许多核心系统中改进跟踪路由的 ADR。

实现效益
很明显，AAF/ADR 方法在早期阶段就能在 Xapo 发挥很好的作用，而且随着各种要素被塑造成符合 Xapo 文化的模式，效益也在不断累积。我们已经提到了由此产生的一些收益，那么还有哪些其他收益呢？

跨职能需求（CFRs）和技术战略虽然不是这种方法的一部分，但也逐渐浮出水面。前者随着 ADR 的提出而自然产生，并在提出时被明确捕捉。由于这些需求已经明确，AAF 的主要代表可以在相关时间点提出他们的需求。例如，来自监管部门的代表和他们在产品组织中的代表能够在技术论坛上从合规的角度明确提出确切的需求。

技术战略的要点也出现了。
首席技术官出席了大多数 AAF，她可以分享自己对总体技术方向的想法，以及她所面临的限制。这些都可以在具体决策的背景下进行讨论，这意味着这些决策不仅与总体战略保持一致，而且还可以在团队日常工作的严酷环境中对战略进行压力测试。不仅如此，通过接触和鼓励参与此类讨论，总体战略得到了广泛的理解。

团队对这些原则的体验和遵守情况也受到了压力测试。
我们已经强调了一个团队及其助理总干事与核心原则接触的最突出的例子，但这种情况以较小的方式一再发生。与战略一样，团队在参与这些对话时，不仅可以就这些原则在现实中是如何形成的提供隐性反馈，还可以提出修改建议。因此，与会者不仅可以抽象地了解整个组织与这些原则的一致性，还可以了解他们在交付软件时与这些原则的一致性；这是一个宝贵的数据点。

AAF 的这种普遍 "感知 "能力在更普遍的方面也很强大。
前面提到的扩展工作的一个关键方面是向明确的领域驱动架构过渡。随着工作的逐周推进，领域语言的使用明显增多。
虽然最初并不总是很明确，也不与有界限上下文相一致，但它被用于特定的 ADR，这意味着可以针对实际问题提供有关关键 DDD 方法的建议。

这加快了对这些不同模式的理解，同时也促进了整个工程团队对领域驱动设计的深入理解，启动了关注领域语言的良性循环，注意到领域语言对耦合和其他关键设计问题的启示（例如，当两个团队明显在谈论领域语言时）。

当发现两个团队在以微妙的不同方式谈论同一个领域概念时，或者他们似乎都倾向于实施一个服务，而这个服务本应由其中一个人实施，而另一个人则委托他人实施），利用这一点在讨论这些设计问题时切中要害，然后部署它们来解决这些问题，从而提高单个团队和整体的效率。

引入 AAF 并不意味着架构师在组织中不再发挥作用。
恰恰相反，我们的小团队一如既往地忙于提供建议、支持 AAF，并将时间集中在对 Xapo 有重大影响的项目上。
赋予团队权力，让这些领域的专家在更接近代码库的地方做出决策，这一举措对实现真正变革所需的时间产生了重大影响。
过去需要花费数周（或数月！）的设计和决策现在只需数天就能完成，这些设计和决策都记录在案，为所有人所理解，并成为我们技术社区集体智慧的一部分。

架构现在是一项集体责任，任何人都可以根据我们的指导原则分享想法或质疑方法。

经验教训
如果我们认为采用这套相互关联的做法、工具、方法和思维方式很容易或没有挑战，那就太疏忽了。其核心是需要转向一种新的 "常识 "系统，这是一种内部的、人类的和群体层面的变革。

最清楚地表明这一点的是，共识带来的舒适感是难以割舍的。
大家应该还记得，"架构建议程序 "只有一条规则："任何人都可以做出架构决定"，既不需要达成一致意见，也不需要寻求更高权力机构的批准。
尽管如此，即使在有意识地放弃这一想法时，"那么，我们都同意吗？"这句话还是会在一次又一次的 AAF 上听到，只是在讨论结束时才悄然脱口而出。
虽然这是一个信号，表明向新思维的转变尚未完成，但这种无意识需求的表达确实让我们能够提醒与会者，共识不是必需的，在没有共识的情况下也可以做出决定并采取行动。

另一个信号是追求与原则一致的 "完美"（不妥协）解决方案。
虽然这种情况发生得较少，但最初很明显，那些在决策方面经验较少的人认为，那些曾经承担这些责任的 "架构师 "们可能只是具有圣人般的智慧，能够找到通往世界最佳的道路。

架构师们对权衡取舍的明确关注和建议，慢慢地打破了这种思维定势，并在 ADRs 中开始明确体现时，真正解决了这一问题。

将这一点公之于众，意味着可以让所有相关人员明白，这种妥协不仅是可以的，而且是不可避免的。

例如，我们认识到，在优化 Xapos 服务以实现团队自治的过程中，工作是重复的。
这是坏事吗？
不一定。
协调和同步的开销往往大于消除重复带来的好处。
讨论的焦点是人们普遍认识到，在某些情况下，重复工作可能会导致用户体验脱节。

在这种情况下，调整工作的益处显然大于弊端。作为一个集体，事先考虑到这一点，对于在作出妥协时把重点放在何处大有帮助。

始终以业务决策为背景做出决定也大有裨益。
很多时候，决定一个方案或另一个方案是否 "最佳 "的因素是产品或业务战略。让产品代表参与到 AAF 的工作中，意味着他们掌握了待定架构决策的所有背景信息，并能相应地分享他们的建议。
一个很好的例子是，产品和设计的基本决定是，无论移动应用程序在哪里使用，无论谁在使用，最重要的是无论平台如何，都要有单一、通用的用户体验。
要确保 iOS 和 Android 体验在任何地方都保持一致，需要付出大量努力，如果没有这一产品指导，就会浪费大量精力。
然而，由于它是整个产品精神和体验的核心，因此至关重要。
了解了这一点，团队就能迅速做出多个战略上一致的决定，而这样做的好处是，在场的每个人都知道为什么。

还值得指出的是，这种定期的同步跟进具有更普遍的好处。
决策不仅可以高效地收集所需的建议输入，而且（更重要的是）在场的每个人，无论决策是否与他们相关，都可以接触到 Xapo 业务和集体推理过程的具体细节。

这在异步返回工作岗位时有惊人的好处，团队可以更清楚地了解 Xapo 每周所走道路的细节和微妙之处。

这一点非常重要，因为没有指导和方向的团队自治会导致混乱。

建议流程（包括责任）等约束条件帮助 Xapo 获得了自由，减少了工程师需要考虑的大量事情。

花时间认真思考 Xapo 的技术支柱和原则也是成功的关键因素。有了这种总体协调和共同理解，再加上每周通过简短的 AAF 进行强化和更新，所有团队都能在专注的时间内实现价值，这一点令人印象深刻。

这些高价值、高影响力的每周会议还有另一个好处：它们让人们可以安全地改变想法，偶尔也可以出错或失败。
包括首席技术官在内的所有人都以此为榜样。
例如，当团队集体学习了更多关于领域驱动设计（DDD）的工具，并看到 Xapo 的软件是如何体现出许多 DDD 模式时，就有必要将服务重新分配给不同的团队，或对其进行重构，使其与更合适的团队及其所处的上下文保持一致。
这并不是说，在团队拓扑改造之初进行的第一团队拆分与理想状态相去甚远，而是可以逐步改进的。通过重构这些责任边界，人们亲眼目睹了设计（包括组织设计）并不需要一开始就是正确的。

为了让这一切发挥作用，很明显，持续、定期地整理 ADR 积压工作和明确 ADR 的所有权非常重要。
此外，在技术内部和外部对整个方法进行内部营销的好处，也让人们将其牢记在心，并看到它的好处。
由于 Xapo 的异步性和全球性，我们决定专门安排一名全职人员负责推动整个工程和其他方面的合作，以确保实现这一点。

在重新考虑各种 ADR 时，就出现了这种有益体现的例子。所有决策都是在某个时间点上做出的，因此应尽可能多地了解当时的具体情况。如果很明显，这一决策背景在未来某个时间点会发生可预见的变化，那么就可以安排重新评估。这种情况发生在 Xapo，当时做出了一个非战略性的托管决策，因为这是当时唯一可行的选择。一段固定时间后，这一决定被重新考虑，随后又进行了一次 ADR，使情况恢复正常，并迁移到战略云提供商上。

在结束本节之前，我们有必要强调一个关键事实：
AAF 和架构建议流程从来都不是孤立存在的。
在 Xapo，前期的基础工作以及现有 Xapien 文化的优势都产生了重大的积极影响。

团队明显受益于向团队-拓扑风格组织结构的转变、对产品思维的同时关注、持续交付基础设施以及 DORA 四个关键指标提供的数据。

从职能型团队模式转变为流式对齐团队（SAT）模式在纸面上看起来很容易。
实际上，这对任何组织来说都是一个巨大的改变。