我们真的需要DDD吗？一年多后，再聊聊DDD
分享下自己接触使用DDD的历程
一、DDD实践总结
一年多前，学习DDD，从理论到一些基础框架比如COLA，当时脑子里有一个想法，把DDD搞明白，运用到项目里，从此告别屎山代码了，走上人生巅峰！完美！但是，你们懂的！
这一年多，也用小项目做实验，尝试了DDD，遇到不少问题：
- 团队成员不了解，包括我自己理解也不是很到位，执行起来很别扭，代码
好像更难维护了（肯定是我自己太菜了，不是DDD不够好） - DDD一直强调是解决复杂业务的利器，但怎么界定复杂呢？一个项目，可能真正算得上复杂的只有一小部分，还有很大部分是简单业务，用DDD的方式开发，总感觉是把复杂的问题搞的更复杂，简单的问题也搞复杂了。
二、开始产生怀疑
一开始是对自己的能力产生怀疑，因为很多DDD的教程都会说，DDD对团队整体能力的要求很高，潜台词就是用了以后效果不好或者产生了副作用，不是DDD的问题，是你和你的团队不行。很长一段时间，导致自己有些郁闷。
因为脑子里留下了这个坎，所以之后看一些开源项目的代码时，总喜欢从DDD的角度看。然后就发现，也没发现复杂项目用DDD呀，但DDD里的部分理念还是有的，比如:业务域只处理业务逻辑，要屏蔽技术细节，比如缓存工具用Redis/Guava/Caffeine实现，业务域应该完全无感。不过，这种概念也不是DDD才有的，只不过DDD把软件设计中的一些设计原则（开闭原则、单一职责、接口隔离、高内聚低耦合等等），通过它的框架又讲了一遍。
总之，对DDD的实用性产生了很大的怀疑。
三、思考，为什么DDD现在这么火
DDD好像就是最近几年突然就火了起来，各种公众号反复的推文，比如《一文看懂DDD领域驱动设计》、《DDD如何从0到落地》等等，这些文章有卖课的，有为了写篇文章而写的（比如我也写过），应该也真的有大厂的大佬分享自己的成功实践。但很大部分都是前两种吧，通过一个简单的案例，写一个DEMO项目，一个人设计业务、写代码、领域建模，的确把人看的一愣一愣的，直呼牛批。
四、实际工作中的情况
实际到了工作中，跟产品经理讲领域建模？和团队成员讲领域分层？和各个团队讲战术设计、战略设计、事件风暴、各种域？我就要一个根据手机壳颜色动态切换app主题，这周上线，你跟我谈战术设计、战略设计、领域模型？你是不是不想做！！
很多公司都是以业务为主，虽然DDD标榜是解决复杂业务系统的利器，但是过于理论，门槛过高，因为有些东西用不好，最多是没有提升，这玩意用不好，直接是负收益。所以，这就导致它不具有普适性。就好比，开发如果追求性能，那应该用C/C++，甚至汇编，但是这个门槛太高了，所以大部分企业开发WEB应用都用java，而不会去追求性能用C。
五、总结，并不是DDD不好
其实，并不是DDD不好，的确有公司、有团队用DDD获得了很好的效果。但使用DDD的确是有很高的门槛和成本在里面，这一点就决定了它不会像spring一样，让开发人员的工作变得更方便，基本上成为开发必备框架（虽然DDD不是框架，只是打个不恰当的比方）。
另外，DDD被吹爆，很大一部分原因是因为现在的培训机构、卖课的在造势，带节奏。把整个圈子搅的，好像不用DDD项目就是垃圾，然后听了这门课就能解决所有问题一样。另外，不乏有些公司招来的架构师和技术管理人员，这些人有一个特点，可能很多年都不实际参与写代码了，所以当他们力推DDD在公司做实验后，把开发团队搞的一团糟，最后简历上添加上重重的一笔：对DDD领域开发有深刻理解，以及落地实践经验。
不过，DDD的理论，对自己写代码还是很有启发的，它的一些理论，对我们平时开发代码时，对业务高内聚的设计，以及技术实现的与业务的分离，都提供了一些很不错的思路。
六、最后，不要为了DDD而DDD
总之，任何一个事物都有它适用的场景和局限性，合适优于先进，简单优于复杂，演化优于一步到位，不要为了DDD而DDD，我们写代码的“第一性原理”应该是：易维护、易扩展、稳定、高效，不管实现方式是什么，如果你的团队可以用DDD达成目的那无可厚非，但一定要避免盲目。
纯属个人的一些思考，有不同意见欢迎交流~~
