DDD，微服务，容器

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

DDD是设计方法，服务架构是一种具体技术实现方式。DDD不一定非要用微服务的方法落地（DDD提出的时间更早）。微服务只是从软件实现的结果说事，没有提供一套方法论来对复杂系统进行分解，从而得到一个个微服务，这个时候就可以用到DDD了。所以，在微服务的书里，基本上都会提到采用DDD的设计方法，

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