背景：由于长期的整体性痛苦，具有联盟模型的国际公司正在转变为微服务。具有快速部署的自治团队是非常可取的。尽管从理论上讲，服务的确确实相互依赖以实现更高的功能，但是服务是自主的（独立开发和部署）。由于这是联邦模式和分散控制，因此我们不能像联合国一样强加严格的规则。由于不同国家生产的版本多种多样，如果没有一个能够管理依赖关系的治理平台，我们将无法控制混乱。
让我们将需要协作的一组微服务称为“兼容性集”。可以部署服务，但可能无法满足其兼容性集中的更高功能。例如，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并没有尝试在系统级进行管理并强制每个服务使用相同的Order定义，而是在协调涉及大量开发人员的大型部署中具有固有的复杂性，并允许每个团队独立工作，根据需要与其他团队进行协调，而不是通过一些集中的依赖性管理系统进行协调。 DDD中使用的术语是有界上下文，其中在一个上下文中，Order表示一件事，而在另一有界上下文中，Order可以表示另一件事。这些上下文可以真正真正地自主运行-您将服务描述为自主的，但是如果它们必须通过向中央注册中心注册并提供依赖项来使它们的顺序定义与整个系统相匹配，那么实际上它们就与其余的紧密耦合在一起。系统及其认为的顺序–最终，您将经历所有痛苦的整体耦合，以及构建分布式系统的所有痛苦，并且如果尝试采用此服务，您将不会意识到微服务的许多好处方法。
因此，基于DDD的方法永远不会尝试采用笨拙的方法在系统级别上增强依赖关系或功能，相反，如果服务A需要与服务B进行交互，则它允许各个团队进行工作而无需中央协调。管理服务A的团队将与管理服务B的团队合作，他们可以在其受限上下文之间建立接口，并就该接口的语言达成协议。这些团队之间必须相互管理依赖关系，在系统级别，事情可以保持不透明/不强制执行。
我们经常看到人们实现“微服务”，但最终得到的系统与整体式系统相比，即使不是更不灵活，通常也更脆弱。也称为“ Minilith”或“ Monolith 2.0”的微服务需要对架构和软件开发流程进行全面的重新思考，不仅需要允许服务自治和独立管理，而且还要求团队独立而不是集中管理。在系统中集中管理依赖项和功能可能会阻碍成功构建基于微服务的系统。
邀请您发表智慧实用的评论...
方法1（治理）是务实和战术性的，旨在解决非常现实的挑战。问题是-它会破坏企业的长期战略DDD模型吗？
方法2（DDD）是理想且理想的方法，但没有解决我们现在必须处理的非常实际的挑战。
意见？思想？注释？
最佳答案
我已经看到跨国公司试图在一个项目上合作（或由一个中央IT团队控制），这是一场噩梦。这种回应是高度主观的，我个人阅读和看过的内容，所以这只是我的观点，可能并不是所有人的观点。通常，不鼓励在Stack Overflow上提出广泛的问题，因为它们会引起高度评价。
我会说DDD可能不是答案。您需要大量的开发人员才能接受DDD的想法。如果您没有买单，那么（除非您有一群非常有上进心的人），您将看到开发人员尝试在现有数据库之上构建新系统。
我也认为microservices aren't the answer。充分利用微服务的公司实际上是在使用微服务，将其代码划分为小的，成堆的独立运行的服务/应用，每个服务/应用都完成一项工作。这些微服务（from the success stories I've seen）倾向于松散耦合。我想如果您拥有大量高度耦合的服务，那么您仍然可以获得整体的意大利面，但是这是spread out over a network。
听起来您只需要一个设计合理的系统，即可满足您的特定需求。我同意使用DDD会很棒，但这在跨国项目中是否是一个现实的目标？
关于domain-driven-design - 微服务依赖性管理-治理还是域驱动设计？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40660163/