DDD起源
DDD，为 Domain-driven design 领域驱动设计的简写，一句话概括，就是：软件代码的结构应该要和业务领域相匹配。
我们先来看看在软件架构演变历史中，DDD是怎么发展起来的，如下图：
(图片来源于我的博客IT宅(itzhai.com，公众号：Java架构杂谈)的另一篇文章：架构演变之路：为何要搞微服务架构？)
-
早在60年代就有了OOP，这个时候，人们就开始意识到面向过程的编程模式对于构建大型软件不太友好，于是开始探索以现实世界的对象的方式去思考编程；
-
直到了1982年，出现了OOAD(面向对象分析和设计)，为OOP的落地提供了指导思想，同时作为解决复杂的业务场景的利器；
-
2000年之后，随着计算机渗透到越来越多的行业，以及互联网的兴起，软件的复杂性增加了，如何应对日趋复杂的软件呢？这个时候，
Eric Evans写了一本书：“Domain-driven Design: Tackling Complexity in the Heart of Software” (领域驱动设计-软件核心复杂性应对之道)，促使人们开始以业务模型去思考软件的设计。但是，人们并没有立刻认识到领域模型的重要性，反而觉得这种软件思想太过于复杂了，于是DDD继续沉睡； -
在2013年，
Vaughn Vernon写了一本关于DDD的书籍：“Implementing Domain-Driven Design”（实现领域驱动设计），提供了一个DDD落地的指导思想，让人们对DDD更加触手可及了； -
诸如
DDD和EIP之类的软件设计自2003年左右就已经开始实践起来了，此时一些团队将应用程序开发为模块化服务，并促使了微服务架构的诞生。-
微服务架构的产生，需要相关技术的支撑，随后的几年，大家把玩各种微服务技术，玩的不亦乐乎：RPC、服务网关、负载均衡、配置中心、消息中间件、分布式任务调度、服务容错、日志监控、DevOps…似乎掌握了这些技术，就离技术的天花板更进一步了。随着微服务技术的不断发展，人们发现每次升级微服务技术，都要对系统进行大量改造，有什么方法可以把业务代码和技术代码更加彻底的隔离开来呢？
-
与此同时，随着业务的演变，人们不断痛苦的拆分微服务。一不小心，拆分过细，导致业务开发更加复杂了。这个时候，人们才开始思考：怎么才能更加合理的拆分微服务呢？
-
终于，大家把目光投向了今天的主角：DDD。
DDD的设计目标：
- 基于领域模型的复杂设计；
- 将项目主要重点放在领域和领域逻辑上；
- 启动技术专家和领域专家之间的创造性合作，不断的迭代改进特定领域问题的概念模型。
基于DDD的设计思想，我们开始把目光回归到软件的核心：业务，开始思考如何让技术更好的为业务服务。
某种程度上来说，面向对象、DDD的思潮，掀起了微服务的狂潮，同时人们在微服务中踩到的技术和服务拆分的坑，促使人们重新意识到DDD的价值。
DDD是万能的吗？
DDD不是银弹，建议将其用于复杂业务，使得可以更好的制定域的通用术语，降低业务的理解难度。
对于简单的业务，DDD不仅不能体现DDD的优势，反而会让开发工作变得更加复杂。
另外，对于探索性的新业务，由于业务模型不能明确下来，也不建议使用DDD，否则会面临不断大力度重构业务领域的问题，导致新业务进展缓慢。在领域知识体系尚未建立的情况下，单体架构可以实现快速开发和迭代。