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