DDD入门之解决了什么问题（二）

DDD⼊门之解决了什么问题（⼆）
DDD(领域驱动设计)的概念出来已经很多年了。

虽然国内好像⽤的⽐较少，令⼈欣慰的是很多⼈已经听说过这个东西了，⼯作中也经常听到领域这个词。

DDD是个啥？它解决了什么问题？
第⼀个问题不好回答，先回答第⼆个。

第⼆个问题讲清楚了，第⼀个问题的答案也就呼之欲出了。

即DDD是解决第⼆个问题的⼀种⼿段/⽅法。

这些都是我个⼈的理解,⽹上看过很多⽂章，他们在讲DDD的时候都会先声明这是他们⾃⼰的理解。

DDD确实有点“⽞学”，不过⼤致还是有迹可循的，很多地⽅⼤家还是能达成共识的。

⽐如DDD试图解决什么问题？我理解的有两个：
1. 业务⼈员跟技术⼈员沟通的问题。

开发⼩伙伴在开需求梳理会的时候经常说⼀些技术名词，⽐如我以前就经常说xx表xx字段之类的。

领域专家们（指精通业务的⼈，⽐如测试同学就是领域专家）听不懂也不关⼼这些，他们经常说领域内的名词，就是他们擅长的领域⾥的“⾏话”。

这其实挺尴尬的，⼤家⾔语不统⼀，沟通成本太⾼，更恐怖的是，技术⼈员可能会把某个概念理解偏了，结果费了九⽜⼆虎之⼒写出来的代码，验收的时候才发现，代码实现的效果压根不是⼈家想要的。

所以DDD要求⼤家（领域专家和技术⼈员）都使⽤同⼀套术语，别再说xx表xx字段（那些是技术实现），也不要把定好的术语⼝头上改成⾃⼰理解术的语。

统⼀术语，就是每个⼈都说这个术语，各⽅都不会理解错误，⽽且最终代码实现的时候，术语在代码⾥都要有体现，整个代码看起来就像是⽤代码把术语翻译了⼀遍⼀样！
2. 代码质量问题
这⾥的代码质量不是指代码是否规范，⽽是说代码是否如实的实现了业务，实现的好不好。

好不好不是说你的程序跑的有多快，⽽是业务逻辑是否清晰。

业务术语，业务规则，业务流程在代码⾥是否有清晰的对应关系。

如果有新的⼩伙伴加⼊，要改⼀个需求，他能否直接通过已有的代码就能把业务梳理清楚，并清楚地知道需要改哪些地⽅。

⽽且改好了之后，确信⾃⼰改的地⽅不会影响其他⼈的代码。

读到这⾥也许你会嗤之以⿐，你⼼想，这可能吗？怕不是痴⼈说梦，理想主义？
理论上，严格以DDD⽅式实现的代码就能做到。

DDD就是要解决上述的“代码质量”的问题。

前提是所有参与编码的⼈，不管是⽼⼈还是新⼈，都熟知DDD的编码规则/习惯。

后续的⽂章⾥我会给出demo代码，你看完DDD这种风格的代码后，就能体会到我所说的。

不出意外，你还会有⼀种如梦⽅醒的赶脚。

好，说完了DDD解决的问题，来看看什么是DDD？
中⽂名叫领域驱动设计，它是⼀种架构模式。

注意架构模式不是架构风格，架构模式采⽤DDD，具体的架构风格可以是六边形架构或者CQRS架构或者六边形架构+CQRS。

很明显，架构模式是个⾼度抽象的东西，是以“领域”为中⼼的指导⽅针，具有⾼瞻远瞩的特性。

怎么感觉越说越像官话了。

总之⼀句话，领导层⽤它来画蓝图（ppt)，底层实现的⼈⽤它来开展业务梳理和编码的⼯作。

DDD的战略⼯具
领导们⽤的，就是划分领域，⼦领域，构建限界上下⽂映射图。

DDD的战术⼯具
这是团队开发⼈员需要关注的，具体的有：
聚合、实体、值对象、领域服务、领域事件。

虽然看起来概念有点多，但是这些概念⾮常重要，⾮常重要，⾮常重要。

这些名词不是什么⾼⼤上的东西，它们只是⼯具。

我们要想把活⼉⼲好，⾸先要了解有哪些可⽤的⼯具，哪些场合应该⽤哪种⼯具。

只有熟悉了这些⼯具的⽤途和使⽤场景，我们才能码出“⾼质量”的代码。

关于DDD的具体内容，这⾥就不详细展开了，⼤家可以去看Martin Fowler和Vaughn Vernon两位⼤神的书。

还有这位博主关于DDD领域模型系列的⽂章总结的⾮常好，我读了后收获很多，⾮常感谢。

推荐给⼤家：
我想把重点放在DDD的实现上，写了⼏年代码，实在受不了三层架构的贫⾎代码了。