DDD 不是一种架构， 而是一种架构方法论， 目的就是将复杂问题领域简单化， 帮助我们设计出清晰的领域和边界， 可以很好的实现技术架构的演进。
DDD涵盖两部分：战略设计部分、战术设计。
战略设计从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
战术设计从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
DDD 看似复杂，学习起来并不困难，但是想要快速掌握 DDD 亦有很多挑战！
微服务并没有一个明确的官方定义，它可以解释为一种架构编程思维，更多地被描述为一种架构风格。微服务架构的概念可以说来源于技术专家多年的工作积累和最佳实践总结，是通过不断发展、演进逐渐形成的。
架构演进论在“技术雷达”里，微服务最早以“Micro-service”，而非“MicroService” 出 现 ， 从 架 构 演 进 的 角 度 来 说 ， 微 服 务 是 从SOA（Services Oriented Architecture，面向服务架构）发展演进而来的，是更先进的细粒度的SOA实现方式。
微服务与DDD
因为DDD是种软件设计思想和方法，没有强制性的技术手段做保障服务与服务之间的边界，Domain和限界上下文之间的“墙”就很容易被打破，不同的Domian和限界上下文就又混在一起，变成一锅粥了。采用微服务技术，会在实现方式上加一些限制，导致这堵“墙”足够厚实，不容易被打破。就像公司中的部门，虽然能造成部门墙，但也保证了不会把所有的事情都搀和在一起，也是有好处的。比如，现在是真的不允许你去任意修改其他模块的代码和数据库了。
微服务从软件实现说事，没有提供一套方法论来对复杂系统进行分解，从而得到一个个微服务，这个时候就可以用到DDD了。所以，在微服务的书里，基本上都会提到采用DDD的设计方法，微服务的一个特性就是具备Bounded Context，这是赤裸裸的跟DDD“暗送秋波”。
