我记得在上一家公司时，我们有个叫红交所的达人探店小程序项目，当时我觉得DDD真的很棒，就用了DDD去架构设计这个项目。那时候我还尝试用DDD的思想去说服产品经理改需求。
结果那个我花了三个月实践DDD的小项目，我花了很多下班时间去不断重构的DDD小项目，在活了几个月后就凉凉了，我前脚离开公司，后脚这个项目就下线了。
那么那一套DDD对这个项目起到了什么作用呢？什么作用都没起到！反而不想因自己选择DDD的原因延误项目进度，白白浪费了自己太多太多业余时间。现在可能连源代码都被人遗忘了。
这个项目都没活过三个月，别提什么传统MVC可能后期迭代会导致项目代码变得不可维护了。更别提什么百万QPS。
我记得那个项目还用了Spring Cloud Kubernetes，是新出不久的一套框架，类似Spring Cloud Alibaba。结果我离职交接的时候，公司找了个外包同学过来接手，让我笑到肚子疼的是，那个人一看代码，就在那里吐槽，怎么没有注册中心，怎么没有配置中心，这哪里是微服务啊，这没法做啊，说完头也不回的走了。因为是我跟他交接，这些话多少是有点说给我听的，我当时只是微微一笑，不想跟陌生人争辩什么。
我不知道他这个选择有没有让他失业。但他的这种思想，对自己不了解的新技术是抵触的，对旧技术是抗拒的，也确实只有外包特别适合他。因为互联网公司，很多大一点的公司都有历史技术债，而一些新项目也会用非常新的东西。而金融行业的，以及国企就更不用说了。肯定没有一家公司能让他待超过一个小时吧。
从另一方面也给我提了个醒，就是技术选项不仅要考虑本身团队的接受程度，也要考虑后来人接手的难度，除非是一些本身对技术就要求非常高的项目。
我们在做技术选型的时候，可能都会陷入一种非理性的状态，容易偏向喜欢用什么技术而做选择。例如，xxx已经是行业标准，很多公司都这么用。
我们去年做过一个云原生项目，那个项目选择了kubevela，选择terraform，这些开源项目一个已经是事实标准，一个想成为标准。但实际开发过程中，我们遇到非常多的问题，而那些问题不是我们改改源码就能解决的。且不说那个项目没能活下来，就算活下来了，也会存在非常多的问题。
但其实如果我们不选择kubevela，而只是自己写个Controller，或许事情就变得简单很多。
做一个产品，在我看来，能实现产品的功能，能让这个产品得到用户的认可，并且产品能稳定运行，能赚钱。背后用的什么技术，又有什么关系呢？用go也好，用java也好，用dubbo也好，用spring cloud也好。
还有动不动就千万架构的，等项目能活下来再说吧。有十万日活再考虑百万日活的事，有百万日活再考虑千万日活的事。不要MVP版本就想着百万QPS，那不扯?吗。有日活才有钱，有钱就能解决所有难题。
我老东家，他们没有自研技术，所有核心能力都用云服务，只专心搞业务。那也不妨碍公司做强做大，做到上市。
几年前，你觉得配置中心就得用Apollo，几年后Apollo几乎无人问津。
几年前，大家都在谈Dubbo，几年后，大家都在谈云原生。
几年前，都在研究怎么限流，几年后，都在研究弹性扩缩容。
几年前，火的是DevOps，几年后火的是平台工程。
所以没必要一味追求用一项技术，技术选型的目的就是选择各方面对比最适合的，这也包括开发成本、运维成本。
技术人追求技术是好事，但应该把精力放在精益求精上，而不是追随潮流。例如，你会用Spring，各种特性用的贼六，但一出问题，你是否都能解决？是否面对所有的异常堆栈，你都能自己解决？是否所有的线上故障你都能独立解决？