DDD专栏11、微服务时代，单体架构淘汰了吗？

​ 上一讲我们重新回顾了DDD在代码设计层面的指导。通过讲解DDD的多种架构模型，解决了"DDD是什么?"的问题。DDD本质上并不是一个全新的技术或者框架，他也是和MVC架构一样，对业务逻辑进行编排和重组后形成的一种逻辑结构。最后，也提出了一种比较直接的DDD代码设计指导方式，就是菱形架构。但是还只介绍了菱形架构是什么，还没有介绍菱形架构到底如何指导程序设计。这一讲，我们将通过讲解菱形架构之间如何协作的问题，来集中解决"DDD到底干什么"的问题。

DDD视角下的微服务

​ 我们这一讲是对DDD进行重新审视，那我们首先从专栏最开始介绍的系统老化的问题说起。在专栏的第一篇，详细的分析了系统老化的各种问题，也提到了DDD使用限界上下文这样一个新的概念来对整个软件进行切分。但是，当时由于对DDD的讲解还不够深，所以对这个问题只能点到为止。现在，当我们经过对DDD一轮的讲解后，再回头来看系统老化的问题，就会发现，系统老化的根源在于没有守住限界上下文。

​ 为什么这么说呢？我们回想一下，在DDD中，我们看到的表象是DDD定义了非常多的逻辑边界，限界上下文、聚合、防腐层等等，不断的规定业务代码能访问哪些功能，不能访问哪些功能。但是在传统的MVC架构中，这些边界在代码层面其实也是存在的，例如很多团队会要求只能通过接口形成直接依赖，Controller只能调用Service，不能直接调用DAO等。但是MVC架构在纵向的业务层面来看，每一层的代码与他的上下文都是绑定的，各种业务线是混杂在一起的。也就是说他们的知识语境是没有切割开的。整个架构看起来会像一座大山，内部虽然有很明显的岩层分隔，但是从外部看&#