DDD(领域驱动设计)的概念出来已经很多年了。虽然国内好像用的比较少，令人欣慰的是很多人已经听说过这个东西了，工作中也经常听到领域这个词。
DDD是个啥？它解决了什么问题？
第一个问题不好回答，先回答第二个。第二个问题讲清楚了，第一个问题的答案也就呼之欲出了。即DDD是解决第二个问题的一种手段/方法。这些都是我个人的理解,网上看过很多文章，他们在讲DDD的时候都会先声明这是他们自己的理解。DDD确实有点“玄学”，不过大致还是有迹可循的，很多地方大家还是能达成共识的。
比如DDD试图解决什么问题？我理解的有两个：
-
业务人员跟技术人员沟通的问题。
开发小伙伴在开需求梳理会的时候经常说一些技术名词，比如我以前就经常说xx表xx字段之类的。领域专家们（指精通业务的人，比如测试同学就是领域专家）听不懂也不关心这些，他们经常说领域内的名词，就是他们擅长的领域里的“行话”。这其实挺尴尬的，大家言语不统一，沟通成本太高， 更恐怖的是，技术人员可能会把某个概念理解偏了，结果费了九牛二虎之力写出来的代码，验收的时候才发现，代码实现的效果压根不是人家想要的。 所以DDD要求大家（领域专家和技术人员）都使用同一套术语，别再说xx表xx字段（那些是技术实现），也不要把定好的术语口头上改成自己理解术的语。 统一术语，就是每个人都说这个术语，各方都不会理解错误，而且最终代码实现的时候，术语在代码里都要有体现，整个代码看起来就像是用代码把术语翻译了一遍一样！ -
代码质量问题
这里的代码质量不是指代码是否规范，而是说代码是否如实的实现了业务，实现的好不好。好不好不是说你的程序跑的有多快，而是业务逻辑是否清晰。业务术语，业务规则，业务流程在代码里是否有清晰的对应关系。如果有新的小伙伴加入，要改一个需求，他能否直接通过已有的代码就能把业务梳理清楚，并清楚地知道需要改哪些地方。而且改好了之后，确信自己改的地方不会影响其他人的代码。
读到这里也许你会嗤之以鼻，你心想，这可能吗？怕不是痴人说梦，理想主义？
理论上，严格以DDD方式实现的代码就能做到。DDD就是要解决上述的“代码质量”的问题。
前提是所有参与编码的人，不管是老人还是新人，都熟知DDD的编码规则/习惯。
后续的文章里我会给出demo代码，你看完DDD这种风格的代码后，就能体会到我所说的。不出意外，你还会有一种如梦方醒的赶脚。
好，说完了DDD解决的问题，来看看什么是DDD？
中文名叫领域驱动设计，它是一种架构模式。注意架构模式不是架构风格，架构模式采用DDD，具体的架构风格可以是六边形架构或者CQRS架构或者六边形架构+CQRS。很明显，架构模式是个高度抽象的东西，是以“领域”为中心的指导方针，具有高瞻远瞩的特性。
怎么感觉越说越像官话了。 总之一句话，领导层用它来画蓝图（ppt)，底层实现的人用它来开展业务梳理和编码的工作。
DDD的战略工具
领导们用的，就是划分领域，子领域，构建限界上下文映射图。
DDD的战术工具
这是团队开发人员需要关注的，具体的有：
聚合、实体、值对象、领域服务、领域事件。
虽然看起来概念有点多，但是这些概念非常重要，非常重要，非常重要。
这些名词不是什么高大上的东西，它们只是工具。我们要想把活儿干好，首先要了解有哪些可用的工具，哪些场合应该用哪种工具。
只有熟悉了这些工具的用途和使用场景，我们才能码出“高质量”的代码。
关于DDD的具体内容，这里就不详细展开了，大家可以去看Martin Fowler和Vaughn Vernon两位大神的书。
还有这位博主关于DDD领域模型系列的文章总结的非常好，我读了后收获很多，非常感谢。推荐给大家：
文章分类 - 领域模型
我想把重点放在DDD的实现上，写了几年代码，实在受不了三层架构的贫血代码了。
