DDD 到底啥，有啥用

带弟弟

DDD 这个东西。。。真不是个人能扛得动的。但熟练运用 DDD ，对于个人写项目也是有极大的好处。

在正常的项目里面，就像上面说的，分为战术和战略两种，战术上其实就是你的类的关系，类和类之间为什么有依赖，为什么应该解依赖。

从战略层面上，就是业务和业务之间的关系，简单的说，用户有订单，订单有用户，但是用户和订单是两个领域。考虑到其他各个地方都有用户，如客服，游戏，退货，这些用户有什么区别，其实是不同上下文里面的所谓用户，本质是不一样的，只有理清楚业务之间的关系，才能设计出良好架构的模块，而这也是微服务划分的关键，界限，上下文。。

DDD 还是好东西，但在公司里面，需要整体配合

个人理解：
DDD 是面向对象的实践总结。
我们在工作中，不必拘泥于 DDD ，不一定要遵守公认的 DDD 的开发模式，只需要使用其中的部分思想就会有很大帮助。
例如：帮助梳理业务流程，帮助团队间更好沟通等等。

DDD 难以落地的原因在于，它不是某项技术，而是思想。非常依赖于团队中关键成员的个人能力。
技术框架是看得见，摸得着的，只要不傻，就能入门。但思想不行。

对同事要求太高，落地十分困难，并且维护不力的话，会是一个四不像，巨坑。

楼上说的对，对同事要求太高，需要你做架构师

DDD 阿里有开源的框架， 你可以看看淘宝技术官方博客写的东西。 我是看了不少， 但是总觉得自己的业务代码套不上去， 太 tm 难受了， 有种别人给你大炮你只能玩驳壳枪的感觉。

我也是一头雾水 然后

作为产品和技术，我感觉我的理解力居然不够用了？ 本来我都是用产品的方法论写代码，利用业务的理解和抽象写代码很轻松而且维护简单

但是一碰到 DDD 我感觉用产品和技术都理解不了...


然后还有我公司的技术负责人水平很一般，他肯定更不能理解... 那就完全推进不了
而且他对于业务真的『毫无用户感知』能力

这个也是我担忧的一点，就是如果只是简单的逻辑剥离，那没是个程序员一般没问题。
如果对于有经验的程序员来说，无非懂得更抽象化一点。

但是对于业务，又不是技术的能力要求... 而且技术和业务思考的维度真的差别蛮大的...

让技术根据业务设计这个事情我就觉得是伪命题...

@jeesk 我也是这种赶紧，尤其是面向对象的设计、与结构化数据存储之间的差异 导致很多问题想不透彻

当下大部分写出来的流水线式的代码在 DDD 面前就是堆辣鸡，领悟了 DDD 你才能发现面向对象和程序描述世界的本质