Domain driven design 微服务依赖管理-治理还是域驱动设计？

背景：一家采用联合模式的国际公司由于慢性疼痛正在向微服务转型。具有快速部署能力的自治团队是非常理想的。尽管从理论上讲，服务确实相互依赖以获得更高的功能，但它们是自主的（独立开发和部署）。由于这是一种联邦模式和分散控制，我们不能像联合国那样强加严格的规则。由于不同国家的生产中存在多个版本，如果没有一个管理依赖关系的治理平台，我们预计会出现无法控制的混乱

让我们将需要协作的微服务集称为“兼容性集”。可以部署服务，但可能不满足其兼容性集中的更高功能。例如，MicroService A-4.3是完全自主的、部署的，并且工作完美。但是，为了满足业务功能8.6的要求，它必须与微服务B-5.4和微服务C-2.9协同工作。它们一起（A-4.3、B-5.4和C-2.9）构成一个“兼容性集”

有两种方法可以解决这一困境。现实生活中的微服务，在这里，橡皮踏上道路，从经验中学习

方法1）治理平台

理由：100多个国家的国际公司采用联邦模式。这意味着中央银行可以制定模式，但各个国家可以选择自己的命运——而且它们经常这样做。它经常会陷入混乱，而中央It团队正处于困境。DDD是一个理想世界的解决方案，在这个理想世界中，版本不一致不会破坏功能，比如发布不符合兼容性集的服务，单独无过错，但一起崩溃或导致有缺陷或不一致的功能

• 没有同质性，甚至没有术语的标准化
• 开发人员技能参差不齐，许多是初级的，许多人学习反应式编程和云本地技术
• 有界上下文严重依赖于共享词汇表，可能会变得很微妙，但在一个国际性的、技能混合的、运行多个版本的碎片化场景中，这是不可能强制执行的，并且是天真的假设
• 在这样一个异构系统中，单一业务模型的标准化是不现实的（但理想的）

当他们被认为是这场混乱的罪魁祸首时，他们该怎么办

实施治理平台 创建Microservices治理系统或框架以实施依赖关系管理。它通过清单在设计和运行时验证和强制特定微服务上的依赖关系，并执行一些检查和平衡，以验证所提供的服务实现——“兼容性集”

方法2）领域驱动设计（DDD） DDD是对不断发展的领域进行建模，领域专家（通常是业务涉众，或者可能是分析师）将与开发人员一起设计系统。在每一个领域中，都形成了一种普遍存在的语言，因此在这种语境中，同一个词总是意味着同一件事。需要意识到的一件重要事情是，在系统的某个部分，“订单”可能意味着一件事，例如，它可能意味着一系列产品。在系统的另一部分，“订单”可能意味着其他东西，它可能意味着发生的金融交易。这就是您描述的模型可能出现故障的地方，如果我的服务需要获得订单列表，可能有一种功能提供订单列表，但它们是哪些订单？产品清单还是金融交易？试图协调尽可能多的开发人员使用相同的语言是一项不可能完成的任务，这是注定要失败的

在DDD中，DDD没有试图在系统级别上管理这一点，也没有强迫每个服务使用相同的顺序定义，而是包含了协调涉及大量开发人员的大型部署的内在复杂性，并允许每个团队独立工作，根据需要与其他团队进行协调，不是通过一些集中的依赖管理系统。DDD中使用的术语是有界上下文，其中在一个上下文中，顺序表示一件事，而在另一个有界上下文中，顺序可以表示另一件事。这些上下文可以真正自主地运行–您可以将您的服务描述为自主的，但是如果它们必须通过注册并向中心注册表提供依赖项来将其顺序定义与整个系统相匹配，然后，它们与系统的其他部分紧密耦合，这就是它所认为的一种秩序——你最终会经历一个整体的痛苦耦合，经历构建分布式系统的痛苦，如果你尝试采用这种方法，你将不会意识到微服务的许多好处

因此，基于DDD的方法永远不会试图采取在系统级别强制实施依赖关系或功能的高压方法，相反，如果服务a需要与服务B交互，它允许单个团队在不需要集中协调的情况下工作，然后，管理服务A的团队将与管理服务B的团队合作，他们可以在其有界上下文之间构建一个接口，并就该接口的语言达成一致。由这些团队来管理彼此之间的依赖关系，在系统级别上，事情可能仍然非常不透明/不强制

我们经常看到人们实现“微服务”，但最终得到的是一个与整体一样（如果不是更灵活的话）脆弱的系统。也被称为“Minilith”或“Monolith 2.0”的微服务需要对体系结构和软件开发过程进行彻底的重新思考，而不仅仅是允许服务自主和独立