眼下在讨论软件架构的时候，DDD、微服务架构和容器技术这三个东西经常会相伴出现。本文希望尽量用大白话给工程师们讲清楚它们之间的区别和联系。很粗浅，很粗浅，技术大牛请略过…

DDD：是Domain Driven Design（领域驱动设计）的缩写。这是一位叫Eric Evans的老兄2004年在一本同名的书中提出的。它是针对复杂系统设计的一套软件工程方法：把系统分割为一个个有边界的上下文（Bounded Context）；通过实体、值对象、聚合等来处理领域的信息；通过服务和领域事件与其他领域耦合；通过上下文地图来表述系统的宏观结构；强调领域专家的作用；强调持续集成和演化…

By Eric Evans – Domain Driven Design Pattern Summaries Word document dddcommunity.org, CC BY 2.5,https://commons.wikimedia.org/w/index.php?curid=9389541

我的体会，DDD是软件工程师们喜欢的那种软件工程方法。为啥？因为提供了比较切实可操作的方法，而不是一堆抽象理论。工程师们就是比较喜欢实打实能落地的玩意呗。

微服务：它是第一次从系统部署和运行的角度对软件的设计提出要求。不像原来的那些SOA的理念，说了半天也不知道怎么保证性能，如何实现集群和横向扩展。你得让软件在云计算时代绷得住呀，否则就是ppt上的忽悠，没法落地呀！

微服务大概是这个意思：传统的大块软件要划分成比较小的、可独立运行的模块；每个服务模块可以用不同的语言去实现（polyglot）；模块之间仅仅通过服务接口和消息队列互相耦合，其他对接方式基本没有；它们很容易被替代（Design for replacement），因而有利于整体系统的持续演化；杜绝微服务之间共享数据库，各管各的数据，传统应用中动不动就是几十、上百张的表，是不能接受的；每个微服务模块都可以保证性能和可扩展性…

微服务的概念，没人会说它不对。实际上，它的理念太对了，是做软件的人一直在追求的目标，以至于人们会怀疑它是不是太理想化了。我们一直被教导，复杂软件应该分割为相互之间低耦合的模块，降低整体的复杂度和修改软件的成本。这么理想的软件架构，真的能实现吗？让软件保持模块化有很多种方法，为什么非得把模块做成微服务这种样子？做成类库、组件什么的不行吗？

DDD的提出者Eric Evans在2015年的一次演讲中，对微服务技术表示了欢迎，认为微服务是让DDD落地的好工具！为什么呢？因为DDD这种设计理念，最好由强制性的技术手段做保障，否则Domain之间的“墙”就很容易被捅破，不同的Domian就又混在一起，变成一锅粥了。采用微服务技术，会在实现方式上加一些刚性的限制，导致这堵“墙”足够厚实，不容易被捅破（从这里我想到，公司里划分部门，虽然能造成部门墙，但也保证了不会把所有的事情都搀和在一起，还是有好处的）。比如，现在是真的不允许你去偷偷访问其他模块的数据库了…

好了，算是说清楚了DDD和微服务架构的关系了吧？前者是设计方法，后者是一种具体技术实现方式。DDD不一定非要用微服务的方法落地（DDD提出的时间更早），但是如果你用微服务架构的话，Eric Evans会投赞成票的。

从另一方面，微服务只是从软件实现的结果说事，没有提供一套方法论来对复杂系统进行分解，从而得到一个个微服务，这个时候就可以用到DDD了。所以，在微服务的书里，基本上都会提到采用DDD的设计方法，微服务的一个特性就是具备Bounded Context，这是赤裸裸的跟DDD眉来眼去好不好:)

容器技术：Docker的火爆让几乎每个工程师都多少了解了容器技术，它也经常跟微服务一起被提起。那么两者的区别是什么呢？

容器技术是更加底层的一种基础设施，甚至有望颠覆以虚拟化技术为核心的传统IaaS。它像集装箱一样把软件封在一个壳子里，然后用标准化的方式把软件部署到服务器上，不管这个软件是用什么语言实现的。

历史上，对软件模块进行封装、部署的技术很多，比如在Java的世界里，我们曾经用EJB、OSGi对软件进行封装，也可以通过动态部署J2EE Web容器的方式实现java程序的集群。但容器技术更先进，它不受具体语言的限制（polyglot），可以建设统一的DevOp基础设施。使用不同语言的程序员之间互掐、互相鄙视的现象，有望大大缓解了，容器技术因此有望获得诺贝尔和平奖提名…

明眼人一下子就能看到：微服务技术和容器技术很容易勾搭到一起。当然，你也可以不采用容器技术来实现微服务。假设你的所有服务都是用go语言写的，都编译成可执行的文件，那不是很方便、很干净地部署吗（go语言当年确实也是这样宣传的）？但是你的数据库怎么办？你的配置文件怎么办？怎么实现集群？当你发现这些东西在容器技术的社区里有越来越成熟的解决方案的时候，你会毫不犹豫地投降变节。

总结起来：DDD、微服务和容器三者，一个比一个更加物理化、工具化、具体化。你可以很容易搞定容器技术，因为它看得见摸得着；但让你设计个微服务，水平可能就有点烂了，因为你划分服务模块的能力不一定行；搞搞DDD，更加难了，每个领域没个10年功夫，很难成为领域专家。

在我们团队，DDD主要让产品组来搞，因为他们有能力、有兴趣跟领域专家对话，划分出正确的Bounded Context；一旦形成领域设计，交付组就可以愉快地实现成微服务；微服务的部署，则由平台组来提供基于容器的基础设施。

这是我们的一点小小经验，希望对各位有点帮助。