DDD是什么？

DDD（Domain-driven design），是领域驱动设计的缩写。

然而，领域驱动设计，是什么？很多书籍，很多博客，都没有对领域驱动设计下一个标准的定义。

就连《实现领域驱动设计》这一本书，也没有对领域驱动设计下了标准化的定义，而是反复描述DDD能解决些什么、应该怎么样做才是DDD。

因为，DDD是一种方法论，是一种指导思想，从不同的视角去看DDD结果是不一样的，因此，不适合对DDD做标准化定义，也无法对DDD做标准化定义。

DDD是站在高维视角上，总览全局。

读懂DDD，需要脱离传统技术人员的视角限制，不仅要用程序员的视角，还要用产品经理的视角、项目经理的视角、以至高层管理的视角。

所以，如果你执着于给DDD下一个定义，那么，就是陷入到思维的囚笼中无法逃脱。

为什么会有DDD出现？

任何事物的发展，生灭，都是有它有必然道理。

DDD不是一个新的发明，只是一个概念被正式提出，在没有提出DDD这个概念之前，DDD就实际上已经是事实上存在了，因为，DDD的真正含义已经是被践行！

回想一下，你所在的公司，当需要开发一个软件系统的时候，是怎么做的？

是不是，需求人员进行需求分析，领导层进行决策，然后进入软件设计，接着是编码，接着是测试，直至软件完成？

假设你是业务人员，你是不是经常与IT人员反复强调自己想要哪些功能，然而做好的功能经常不是自己想要的？你想将你的想法毫无保留地告诉IT人员，然而IT人员经常不知道你在说啥。

假设你是需求人员，你是不是经常在想，这个需求是否是合理的？是不是经常疑惑，用户到底想要些什么、怎么样才能解决用户的痛点？

假设你是设计人员，你是不是经常因为不停变化的需求而不停地大范围修改自己的设计？是不是经常因为需求很复杂，而觉得设计工作无所下手？

假设你是编码人员，你是不是经常因为看不懂设计人员的文档，或者根本就没有设计文档而苦恼？是不是经常因为需求的变化，而需要对代码进行大范围的改动？

假设你是测试人员，你是不是经常因为开发拖堂而没有足够的时间测试？是不是经常因为开发bug多而工作量大？

软件开发的每一个阶段，都充满了不确定性，上一个阶段的风险往往在下一个阶段才会暴露，随时软件开发的时候越长，软件开发所承受的风险就越大，随之而来的失败概率也就越大。

正是因为有这么多的问题存在，所以业界大佬才提炼出了DDD。

DDD能做些什么？

DDD出现的原因，就是DDD能做些什么！

很多公司发现在研发软件的过程中，发现项目越大、周期越长，风险就越大，急需一种能有效降低风险的解决方案。

践行DDD，能有效地降低软件开中遇到的风险，使软件能顺利交付。

我们能做DDD吗？

能做DDD，与真正做到DDD，是两回事！很多团队觉得自己能做DDD，但在践行DDD的时候却没有做到DDD。古人说：名与实符。如果只是把DDD挂在口上，而不去践行，那么永远是纸上谈兵，是名DDD，而非DDD。

思维是一道无形的墙，把人牢牢的锁在里面，如同坐井之蛙，看不到天地之阔，也看不到世代的波澜壮阔。

古人说：破而后立，革旧鼎新。

《易经》又说：穷则变，变则通，通则达，达则久。

要想践行DDD，得先打破思想的囚笼。让软件开发者具备产品思维，学会站在产品的角度思考问题。让业务人员具备一定的软件知识，学会使用软件开发者的视角看问题。

思维的格局打开之后，再回来看DDD，你会发现DDD的思想充满着哲学的智慧。

在践行DDD的时候，要避免教条主义，不能死板地照搬书中的内容，也不能完全不动地复制他人的DDD成果，要结合自身的条件，发展出符合自身的DDD。

结语

读到这里，你明白DDD是什么了吗？

没有明白也不要紧，接下来的文章会带你走进DDD，从实践中领悟DDD！