背景：一家采用联合模式的国际公司由于长期的单体痛苦正在向微服务转型。具有快速部署的自治团队是非常可取的。尽管有理论，服务确实相互依赖以获得更高的功能，但是是自治的（独立开发和部署）。由于这是一个联邦模式和分散控制，我们不能像联合国一样强加严格的规则。由于不同国家/地区生产的多个版本，如果没有一个可以管理其他依赖关系的治理平台，我们预见到无法控制的混乱。
让我们将需要协作的一组微服务称为“兼容性集”。可以部署服务，但可能无法满足其兼容性集中的更高功能。例如，MicroService A-4.3 是完全自主的、已部署的并且可以完美运行。但是，要满足 BusinessFunctionality 8.6，它必须与 MicroService B-5.4 和 MicroService C-2.9 一起使用。它们一起（A-4.3、B-5.4 和 C-2.9）形成一个“兼容性集”
有两种方法可以解决这个困境。现实生活中的微服务，橡胶上路，从经验中学习开始......
方法一）治理平台
理由： 100 多个国家/地区的国际公司的联邦模式。这意味着中央 IT 可以制定模型，但各个国家可以选择自己的命运——而且他们经常这样做。它经常陷入混乱，中央 IT 团队陷入困境。DDD 是一个理想世界的解决方案，其中版本不一致不会破坏功能，例如发布不适合兼容性集的服务，单独无可指责，但它们一起分崩离析或导致有缺陷或不一致的功能。
- 没有同质性，甚至没有术语的标准化
- 开发人员技能混杂，很多初级，很多学习反应式编程和云原生技术
- 限界上下文在很大程度上依赖于共享词汇，它可能会变得微妙，但在一个国际化、混合技能、碎片化的场景中运行多个版本是不可能强制执行和幼稚的假设
- 在这样的异构系统中，单一业务模型的标准化是不现实的（但很理想）
当中央 IT 对这种混乱负责时该怎么办？
实施治理平台 创建微服务治理系统或框架以实施依赖管理。它在设计和运行时通过清单验证和强制执行对特定微服务的依赖关系，并执行一些检查和平衡以验证所提供的服务实现 - “兼容性集”。
方法 2) 领域驱动设计 (DDD) DDD 是关于对不断发展的领域进行建模，领域专家（通常是业务利益相关者，或者可能是分析师）将与开发人员一起设计系统。在每个领域中，形成了一种无处不在的语言，因此在该上下文中，同一个词总是意味着同样的事情。需要意识到的重要一点是，在系统的一部分中，“订单”可能意味着一件事，例如，它可能意味着产品列表。在您系统的另一部分，“订单”可能意味着其他东西，它可能意味着发生的金融交易。这是您描述的模型可能失败的地方，如果我的服务需要获取订单列表，也许那里有提供订单列表的功能，但它们是什么命令？产品清单还是金融交易？试图协调尽可能多的开发人员在这里使用相同的语言是一项注定要失败的不可能任务。
在 DDD 中，与其尝试在系统级别进行管理并强制每个服务使用相同的 Order 定义，DDD 包含了协调涉及大量开发人员的大型部署的固有复杂性，并允许每个团队独立工作，根据需要与其他团队协调，而不是通过一些集中的依赖管理系统。DDD 中使用的术语是有界上下文，其中在一个上下文中，Order 表示一件事，而在另一个有界上下文中，Order 可以表示另一件事。这些上下文可以真正自主地运行——你将你的服务描述为自主的，但如果它们必须通过注册并提供依赖关系到中央注册表来将它们的顺序定义与整个系统相匹配，
因此，基于 DDD 的方法不会尝试在系统级别强制执行依赖项或功能，而是允许单个团队在不需要中央协调的情况下工作，如果服务 A 需要与服务 B 交互，那么管理服务 A 的团队将与管理服务 B 的团队合作，他们可以在他们的有界上下文之间建立一个接口，并就该接口的语言达成一致。由这些团队来管理彼此之间的依赖关系，在系统级别，事情可能会保持相当不透明/未强制执行。
我们经常看到人们实施“微服务”，但最终得到的系统与单体应用相比，即使不是更不灵活，也往往更脆弱。也称为“Minilith”或“Monolith 2.0”微服务需要对架构和软件开发流程进行彻底的重新思考，不仅需要让服务自主和独立管理，还需要让团队独立，而不是集中管理。集中管理系统中的依赖项和功能可能会阻碍成功构建基于微服务的系统。
聪明务实的评论邀请...
方法 1（治理）是务实和战术性的，旨在解决非常现实的挑战。问题是——它会破坏企业的长期战略 DDD 模型吗？
方法 2 (DDD) 是理想的和有抱负的，但并没有解决我们现在必须应对的真正挑战。
意见？想法？注释？