为什么设计微服务时需要 DDD？

记得当时我在规划设计微服务架构的时候，张队长给我的一个提醒，至今我还记得很清楚：为什么你的设计蓝图中看不到DDD的影子？

随着我对拥堵模型领域理解的加深，我越来越感受到DDD的重要性。于是我就上网查资料，做学习笔记。

DDD内容非常多。依我拙见，它区别于传统贫血的核心点就是从原来的传统贫血模型中取出业务逻辑层，融入到Domain层中。这样，面对复杂业务的大规模变化，我们只需要关注Domain即可。

回到正题，我们需要了解的是微服务和DDD是什么关系？

因为在互联网时代，软件面临的问题域比以前复杂得多。这种复杂性来自于不断扩大的问题领域本身，也来自于这种大规模增长所带来的创新变化和挑战。挑战。

然而，作为一个人和一个团队，他对复杂事物的理解是有限的。面对如此复杂的问题，唯一的办法就是分而治之。划分主要考虑的是如何划分；治理意味着各个独立部分必须能够独立运作、相互协作、完成总体目标，并能够应对外部变化的影响。

微服务的缺陷

微服务架构在划分和治理方面都提供了很好的理论指导和最佳实践。那么微服务是解决复杂问题的灵丹妙药吗？事实上，情况并非如此。很多团队应用微服务架构构建系统后，发现这个复杂性问题并没有完全解决，甚至引发了一些其他问题。例如：

• 服务并不能解决复杂系统如何响应需求变化的问题，甚至还会加剧问题。
• 当需求发生变化时，需要花费大量精力来确定哪些微服务受到变化的影响。这些服务的多个团队需要经过无休止的争论来决定哪些服务需要更多的改变，哪些服务需要更少的改变。一些。
• 那么测试团队还需要做昂贵的联调测试
• 即便如此，开发团队还是心有余悸，不得不使用一系列的开关控件来小心切流，做灰度发布。 。

从业务角度来看，微服务架构并不能避免这种分散的修改。甚至让他心情更加沉重。为什么是这样？一个重要的原因是微服务架构在这个维度上考虑的不够全面。

DDD功能

我们做这样的工作时，需要考虑哪些维度？我认为我们至少需要考虑三个维度：

• 功能维度
• 质量维度，如性能、可用​​性
• 工程维度

微服务对第二个维度给出了很好的指导，对第三个维度也给出了一些建议。然而，对于第一个功能维度只给出了非常有限的指导，这就是为什么随着微服务的流行，领域驱动设计（DDD）再次受到关注。

DDD弥补了微服务在功能划分上没有很好指导的缺点。因此，他们在面对复杂问题和构建系统时是互补的关系，在系统拆分时能够很好地协作。

只是他们看待系统分裂的角度不同而已。微服务中的服务范围正是DDD所倡导的六边形架构中的领域层。