领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。
直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。
不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。
不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。
我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。
同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。
（DDD相关的经典论著）
一、关于DDD的误区DDD是解决大型复杂项目的，我们当前业务比较简单，不适合DDD。
DDD要有一个完整的、符合DDD原则的代码结构，这可能增加代码的复杂度，有可能导致项目进度失控。
DDD是一种框架，应该包含聚合根、实体、领域事件、仓储定义、限界上下文等一切DDD所倡导的元素；否则你就不是DDDer。
DDD需要大家严格遵循各自模块的边界，且存在着过多因为解耦带来的看似冗余没用的代码，会降低编码效率，造成“类膨胀”。
二、DDD离我们很近DDD是什么？众里寻她千百度，蓦然回首，“DDD是一种可以借鉴的思想，而非严格遵循的方法论”。
1、领域驱动设计中的领域模型当我们面向业务开发的过程中，应该首先思考领域模型而不是如何建表。
我听过太多业务开发的声音，“面试造航母、工作拧螺丝”，日常工作就是建表写增删改查。为什么会有这样的认知，其根源在于表驱动设计思想而非领域驱动设计。
前者只能增加数据库的表数量，而后者才会形成长期的、具有业务意义的模型，这样的系统生命力才更加长久。我们也才能用工程的方法来编码，从编码转身为业务域的开发专家。
有很多关于领域驱动设计的论述中都并未明确我们如何得到“领域”，只有合理的领域模型才能有效驱动设计开发。所以建好领域模型是关键，对于领域模型的思考与技术框架升级同样重要。我曾经在互联网部门分享过如何进行领域建模，也欢迎大家与我交流沟通，有兴趣的读者也可以重点阅读一下《UML和模式应用》相关章节。
2、架构与解耦
在讨论DDD之前我们先来讨论一下“解耦”，这个词是我们在日常编码时候经常提及的词语。一个具有工匠精神的程序员一定会在代码审查阶段对一些巨无霸函数或者类进行拆分，使各部分的功能更加聚焦、降低耦合。
另一方面，在架构方面我们也会重视“解耦”，因为一个模块之间随意耦合的系统将是所有人的噩梦之源。因此，除了整洁的代码我们还需要关注整洁的架构。
架构的三要素：职责明确的模块或者组件、组件间明确的关联关系、约束和指导原则。内聚的组件一定有明确的边界，而这个明确的边界必然作为相关的约束指导今后的发展。
分层架构是运用最为广泛的架构模式，几乎每个软件系统都需要通过层来隔离不同的关注点，以此应对不同需求的变化，使得这种变化可以独立进行；各个层、甚至同一层中的各个组件都会以不同速率发生变化。