Domain-Driven Cloud（DDC）是一种根据你的业务模型创建组织云架构的方法。DDC 使用你的业务模型的限界上下文作为输入，并输出一个灵活的云架构，以支持组织中的所有工作负载，并随着业务变化而演进。DDC 通过为团队提供创新的能力，在保护范围内促进团队自治。在运营方面，DDC 以一种促进 IT 和业务利益相关者彼此透明的方式，简化了安全性、治理、集成和成本管理。
基于领域驱动设计（DDD）和高内聚低耦合的架构原则，本文介绍了 DDC，包括将你的云架构与业务模型的限界上下文对齐所带来的技术和人员收益。你将了解如何在亚马逊网络服务（AWS）和微软 Azure 等云平台上实施 DDC，并与它们的良构架构框架对齐。通过我们一个真实客户的示例，你将学习在你的组织中实施 DDC 的 5 个步骤。
什么是领域驱动云（DDC）？
DDC 将 DDD 的原则扩展到传统软件系统之外，创建了一个统一的架构，涵盖了业务领域、软件系统和云基础设施。
我们的客户始终努力对齐“人员、流程和技术”，以便能够协同工作，实现业务目标。然而，在实践中，往往事与愿违，因为业务（Biz）、IT 开发（Dev）和 IT 运营（Ops）都各自为营，从自己的角度为横跨这三个领域的复杂问题在设计解决方案。
最后的结果就是不同团队使用不同方法和本地化语言设计和实施的业务流程重新设计、企业架构和云平台架构。
缺失的是使用共享语言的统一架构方法来集成 BizDevOps。这就是 DDC 的作用所在，它专注于将云架构和运行其上的软件系统与使用 DDD 确定的业务模型的限界边界上下文保持一致。图 1 显示了 DDC 如何扩展 DDD 的原则，包括云基础设施架构，从而创建一个对齐 BizDevOps 的统一架构。
在 DDC 中，最重要的云服务是包含账户的 AWS组织单位(OU's)和包含订阅的 Azure管理组(MG's)。因为你所保护、使用和支付的 100%云资源都与账户和订阅相关联，所以它们是自然的成本和安全容器。通过在更高的 OU/MG 级别启用管理和安全，并将其锚定在业务模型的限界上下文上，你现在可以创建一个涵盖业务、开发和运维的统一架构。在满足特定需求时，你可以为团队提供使用账户和订阅的灵活性。
为什么要将云架构与业务模型相一致？
将云架构与组织的业务模型保持一致有以下好处：
随着业务发展而演进 - 企业不是静态的，你的云架构也不是。随着市场的变化和业务的发展，新的上下文可能会出现，而其他上下文则可能会巩固或消失。一些过去注重战略差异化的上下文今天可能带来较少的商业价值。将云管理、安全和成本直接与限界上下文对齐，意味着你的云架构会随着业务的发展而演进。
提高团队的自主性 - 尽管某些云管理任务必须集中进行，但 DDC 建议在领域上下文中给予团队自主权，如基础架构的供应和应用程序的部署。这样一来，你的敏捷团队可以更快地前进，并对业务增长的变化做出更敏锐的响应，从而促成“有保障的创新”。这还确保了不同上下文中工作负载之间的依赖关系是明确的，目标是促进与授权团队一致的松散耦合架构。
促进高内聚和低耦合 - 将网络与限界上下文对齐，可以明确允许或拒绝所有上下文之间的网络连接。这是非常强大的，尤其对于在云平台上实施低耦合的现代架构而言。在一个上下文中，团队和工作负载理想情况下在安全性、网络集成和支持业务特定部分方面具有高内聚性。你还可以自由地在限界上下文和工作负载级别上做出可用性和弹性决策。
增加成本透明度 通过将你的限界上下文与 OU 和 MG 对齐，所有云资源使用情况，预算和成本都可以精确地以细粒度进行跟踪。然后，它们会在限界上下文中自动汇总，无需自定义报告和打扰所有工程师来标记所有内容！通过 DDC，你可以查看每个限界上下文的每月云账单，并了解确切的云支出，从而使你能够评估这些成本是否与每个上下文的业务价值相符。云预算和警报可以委派给与上下文对齐 的团队，使他们能够监控和优化他们的支出，同时你的组织对整体云成本有清晰的自上而下的视图。
与领域对齐的安全性 - 安全策略、控制、身份和访问管理都与限界上下文很好地对齐。一些策略和控制可以在所有上下文中部署，以创建强大的安全基线。从这里，可以安全地将选定的控制委派给团队进行自我管理，同时仍然强制执行企业安全标准。
可重复使用的代码模板 - AWS 和 Azure 都提供了从基于代码的蓝图持续预备新的帐户或订阅的方法。在 DDC 中，我们建议为所有领域上下文定义一个模板，然后使用此模板（加上可配置的输入参数）根据需要提供和配置新的 OU 和帐户或 MG 和订阅。这些管理结构是免费的（你只需支付其中使用的实际资源），使你能够逐步构建云架构，朝着明确的未来状态发展，而不会产生额外的云成本。
DDC 可能并不是所有情况下的最佳方法。其他选择，比如按照租户/客户（SaaS）或法人实体组织云架构，也是可行的选项。
不幸的是，我们经常看到客户按照他们当前的组织结构来组织他们的云架构，遵循着上世纪 60 年代的康威定律（Conway's Law）。我们认为这是一个错误，而 DDC 是一个更好的选择，原因很简单：你的业务模式比你的组织结构更稳定。
好的架构的核心原则之一是我们不应该让更稳定的组件依赖于不稳定的组件（也称为稳定依赖原则）。组织机构，尤其是大型机构，经常喜欢重组，这使得他们的组织结构比他们的商业模式更不稳定。基于组织结构构建云架构意味着每次重组时都会直接影响到你的云架构，这可能会影响到云环境中运行的所有工作负载。为什么要这样做呢？基于组织的商业模式构建云架构可以使其随着你的业务战略的发展而自然演化，如图 2 所示。
我们认识到，正如 Ruth Malan 所说的那样：“如果系统的架构与组织的架构不一致，组织的架构将占上风”。我们也承认，达到 OU（组织单元）/ MG（管理组）以及其中的所有工作负载与团队边界和责任之间的最佳对齐状态仍有待努力。我们认为像Team Topologies这样的理念可能会在这方面提供帮助。
我们看到当今的组织正在摒弃独立的部门项目和正式沟通结构，转向跨职能团队创建跨越组织边界的产品和服务。这些现代解决方案在云上运行，因此我们认为现在是以共享语言和架构方法统一业务、开发和运维的企业架构的时机。
Well-Architected 框架怎么样？
亚马逊云服务的Well-Architected框架和微软Azure的Well-Architected框架都提供了一套经过精心策划的设计原则和最佳实践，用于设计和操作云环境中的系统。DDC 完全支持这些框架，并且在 SingleStone 我们与客户一起使用这些框架。虽然这些框架为将工作负载组织成多个帐户或订阅，并使用 OU 和 MG 进行管理提供了具体的建议和好处，但它们会让你自行决定最适合你组织的分类方式。
DDC 倾向于基于限界上下文构建云架构，同时与 AWS 的 Separated AEO/IEO 模型和“执行操作即代码”以及“自动从故障中恢复”的设计原则完全兼容。你也可以采用 DDC 并应用这些最佳实践。AWS Landing Zone 和 Azure Landing Zones 等工具可以加速设置云架构，并且也符合领域驱动的原则。
实施领域驱动云的五个步骤
你认为在 BizDevOps 中使用共享语言的统一架构能够使你的组织受益吗？虽然本文无法详尽列出所有任务，但以下是你可以遵循的五个基本步骤，其中包含了最近迁移到 Azure 的一位客户的示例。
步骤 1：从限界上下文开始
实施 DDC 的起点是一组描述你业务模型的限界上下文。本文不涵盖确定限界上下文的步骤，但领域驱动发现中描述的过程是一种方法。
确定限界上下文后，将它们组织成两个组：
领域上下文直接与你的业务模型对齐。
技术上下文通过共享基础架构和服务来支持所有领域上下文。
为了说明，让我们看一下一位医疗用品公司的客户。他们的领域和技术上下文如图 3 所示。
你组织的领域背景可能会有所不同。
对于技术上下文，数字将取决于你组织的行业、复杂性、监管和安全要求等因素。一家财富 100 强的金融服务公司将拥有比一家新媒体初创公司更多的技术上下文。话虽如此，作为起点，DDC 推荐为支持所有系统和数据设置六个技术上下文。
云管理 上下文用于配置和管理云平台，包括 OU/MG（组织单位/管理组）、账户/订阅、云预算和云控制。
安全 上下文用于身份和访问管理、密钥管理和其他任何工作负载使用的共享安全服务。
网络 上下文用于所有集中式网络服务，包括子网、防火墙、流量管理和本地网络连接。
合规性 上下文用于支持监管、审计和取证活动的任何合规性相关服务和数据存储。
平台服务 上下文用于包括 CI/CD、软件包管理、可观察性、日志记录、计算和存储在内的常见开发和运维服务。
分析 上下文用于企业数据仓库、治理、报告和仪表板。
你无需一开始就创建所有这些上下文，可以从云管理开始，根据需要逐步构建。
步骤 2：打造坚实的基础
在定义了你的限界上下文之后，现在是时候为支持你的组织工作负载建立一个安全的云基础了。根据我们的经验，我们发现将云能力按照它们对工作负载的支持方式分为三个层次进行组织是很有帮助的。对于我们的医疗用品客户，图 4 显示了他们的上下文与应用程序、平台和基础层的云架构对齐。
使用 DDC，你可以将 AWS 组织单位（OU）或 Azure 管理组（MG）与限界上下文对齐。所谓对齐，是指将它们命名为你的限界上下文。这些是管理的最高级别，并通过继承的使用使你能够在整个云架构中标准化控件和设置。
DDC 使你能够以最佳方式组织你的帐户和订阅分类法，从粗粒度到细粒度，如图 5 所示。
DDC 建议从一个 OU/MG 和至少两个限界上下文的帐户/订阅开始。如果你的组织有更高的工作负载隔离要求，DDC 也可以支持，如图 5 所示。
对于我们的客户来说，他们的小型云团队刚开始接触 Azure，为每个上下文设置独立的生产环境和非生产环境的订阅是个合理的起点，如图 6 所示。
图 7 展示了在 AWS 中的样子。
对于我们的客户，可以在各自的生产环境和非生产环境订阅中创建 Dev、Test 和 Stage 等进一步的环境。这为他们提供了在订阅或更低级别中，配置环境特定设置的能力，同时保持了环境之间的隔离。他们还决定仅为六个技术环境构建生产环境的订阅，以便开始的时候保持简单。如果你的组织希望为每个工作负载环境创建单独的账户或订阅，也可以实现，并与 DDC 保持一致。
从治理的角度来看，在 DDC 中，我们建议领域上下文从技术上下文继承安全控制和配置。在技术上下文中创建强大的安全姿态，使得在领域上下文中运行的所有工作负载都可以默认继承此安全性。然后，领域上下文可以根据情况选择性地覆盖某些控制和设置，以平衡团队自治和灵活性与所需的安全防护。
使用 DDC，你的组织可以赋予团队自主权，在防护栏杆内实现创新。借助团队拓扑的关键概念，在创建云基础设施、部署发布和监控工作负载时，流程对齐的团队可以在领域上下文中自给自足。主要在技术上下文中工作的平台团队可以专注于设计和运行流程对齐团队使用的高可用服务。这些团队共同努力，在集中化和分散化云控制之间找到合适的平衡，以满足组织的安全性和风险要求，如图 8 所示。
正如这个图所示，定义在较高级 OU/MG 中的政策和控制会向下执行，而成本和合规性会向上报告。对于我们的医疗用品客户来说，这意味着他们的每月 Azure 账单会自动按照其限界上下文进行细项列示，其中包括订单、分销商和支付方等的云成本总结。
这使得他们的首席技术官可以轻松地与业务伙伴共享云成本，并建立可以随时间监控的现实预算。与成本类似，所有上下文中的政策合规性可以向上报告，并在合规性技术上下文中存储证据，以用于审计或取证目的。像 Azure Policy 和 AWS Audit Manager 这样的服务有助于通过将政策和控制集中管理，持续维护云环境的合规性。
步骤 3：将工作负载与限界上下文对齐
在打下坚实基础并确定了限界上下文之后，下一步是将工作负载与限界上下文对齐。通常，确定将在云环境中运行的所有工作负载是在云迁移发现过程中完成的，部分借助于变更管理数据库（CMDB），该数据库包含你的组织应用程序的投资组合。
在将工作负载与限界上下文对齐时，我们更倾向于采用一种促进讨论和协作的研讨会方法。根据我们的经验，这使得迁移相关的团队能够理解 DCC 并产生共鸣。由于团队必须开发和支持这些工作负载，研讨会还能够突出组织结构与限界上下文之间是否能够对齐的地方。在这个研讨会（或后续研讨会）中，还可以确定哪些应用程序应该具有独立可部署性，以及团队的所有权边界如何与限界上下文对应。
对于我们的医疗用品客户，这个研讨会揭示了在共享服务上下文中部署新版本订单管理系统所需的共享 CI/CD 工具的权限。这引发了一场关于如何跨上下文管理机密信息和权限的讨论，确定了在云迁移期间优先考虑的新的机密信息管理能力。通过创建一个适用于领域上下文中所有未来工作负载的可重用解决方案，云团队创建了一个新的能力——提高了未来迁移的速度。
图 9 总结了我们的客户如何将工作负载与限界上下文对齐，并将其与 Azure 管理组对齐。
在订单的上下文中，我们的客户使用 Azure 资源组来独立部署包含 Azure 资源的应用程序或服务，如图 10 所示。
这个设计为他们最初从数据中心迁移到 Azure 的应用程序提供了一个起点。在接下来的几年里，他们的目标是将这些应用程序重构为多个独立的微服务。当时机成熟时，他们可以通过为每个服务创建额外的资源组，逐步地按应用程序进行重构。
如果我们的客户使用的是 AWS，图 10 看起来会非常相似，但使用组织单位、账户和 AWS 技术栈来组织独立部署的应用程序或包含资源的服务。云服务提供商之间的一个区别是，AWS 允许嵌套技术栈（技术栈内嵌技术栈），而 Azure 资源组不支持嵌套。
对于网络，在领域上下文中运行的工作负载要访问技术上下文中的共享服务，它们的网络必须连接或显式启用权限以允许访问。虽然网络技术上下文包含集中的网络服务，但默认情况下，与领域上下文对齐的每个账户或订阅都将拥有自己的私有网络，其中包含由其内部运行的工作负载独立创建、维护和使用的子网。
根据账户或订阅的总数，可能是期望的也可能是太多的独立网络需要管理（每个网络可能有自己的 IP 范围）。或者，可以在网络上下文中定义核心网络，并与特定的领域或技术上下文共享，从而避免每个上下文都拥有自己的私有网络。云网络的详细信息超出了本文的范围，但 DDC 可以实现多种网络选项，同时将你的云架构与业务模型保持一致。底线是：你无需牺牲网络安全性来采用 DDC。
步骤 4：迁移工作负载
现在我们已经确定了每个工作负载将在哪里运行，是时候开始将它们移动到正确的账户或订阅中了。虽然这对我们的客户来说是一次新的迁移（绿地），但对于你的组织来说，这可能涉及重新架构现有的云平台（棕地）。将一系列工作负载迁移到 AWS 或 Azure 以及架构云平台的步骤超出了本文的范围，但就 DDC 而言，以下是需要记住的主要事项清单：
根据你的限界上下文为 AWS 组织单位（OU）或 Azure 管理组（MG）命名。
将上下文组织成领域和技术分组，包括：
将技术上下文作为云架构的基础和平台层。
将领域上下文作为云架构的应用层。
在技术上下文中集中常见的控制，以确保强大的安全姿态。
在领域上下文中分散选定的控制，以促进团队的自治、速度和敏捷性。
在 OU 或 MG 内使用继承来向下强制执行策略和控制，同时向上报告成本和合规性。
在 OU / MG 内决定你的账户/订阅分类法，平衡工作负载隔离和管理复杂性。
决定你的网络如何映射到域和技术上下文，平衡集中化与分散化。
为一致性创建领域上下文模板，并在为新的账户/订阅进行配置时使用这些模板。
对于既有云架构的 DDC 的棕地部署，基本步骤如下：
创建以你的限界上下文命名的新 OU（组织单位）/ MG（管理组）。在一段时间内，这些将与你现有的 OU / MG 并行存在，并且不应对当前操作产生任何影响。
在新的 OU / MG 中根据技术上下文实施策略和控制，并适当使用继承。
为所有领域上下文创建一个通用代码模板，该模板从你的技术上下文继承策略和控制。对于上下文之间的任何不同之处，使用参数进行设置。
根据你的工作负载映射研讨会的输出，针对每个工作负载执行以下操作之一：
a. 使用通用模板创建一个新的帐户/订阅，与你期望的帐户分类法保持一致，用于容纳工作负载；或者
b. 迁移现有的帐户/订阅，包括其中的所有工作负载和资源，到新的 OU / MG。迁移时，请仔细注意来自原始 OU / MG 的控制措施，确保它们也在目标 OU / MG 中启用。
你移动工作负载的顺序将由工作负载之间的依赖关系来决定，在开始之前应明确了解。共享服务所依赖的工作负载也是如此。
根据要迁移的工作负载数量的不同，这可能需要几周或几个月的时间（但希望不是几年）。在迁移工作负载时要有条不紊地进行工作，验证每个上下文的控制、成本和合规性是否正常运行。
完成后，废弃旧的 OU / MG 结构和不再使用的任何帐户/订阅。
步骤 5：检查和调整
你的云架构不是静态的工件，随着业务的变化和新技术的出现，设计将继续发展。新的限界上下文会出现，需要对你的云平台进行更改。理想情况下，这项工作的大部分都是通过编码和自动化来完成的，但很可能你仍然需要一些手动步骤，因为限界上下文也在演化。
你的帐户/订阅分类法也可能随时间而变化，开始时较少，以简化最初的管理，但会随着团队和流程的成熟而逐渐增长。团队的责任边界以及它们如何与限界上下文对齐，也会随时间而成熟。像 GitOps 这样的方法与 DDC 结合使用，可以使你的云基础架构随时间而灵活和可扩展，并始终与你的业务模型保持一致。
结论
DDC 扩展了 DDD 原则，将其应用于传统软件系统以外的领域，创建了一个统一的架构，跨越业务领域、软件系统和云基础设施（BizDevOps）。DDC 基于软件架构的高内聚低耦合原则，用于设计复杂的分布式系统，比如 AWS 和 Azure 环境。在创建组织的云架构时，应用 DDD 的透明性和共享语言的优势，可以得到一个安全而灵活的平台，随着业务随时间的变化而自然演化。
原文链接：
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论