大块头转型微服务，只有迭代太快，复杂几何级别的增加

做过ERP的人都知道，要满足各种销售端需求，尤其是最saas，需要加入相当多的业务，如果说ERP还算好，那么WMS系统除了要满足销售端，更要满足各种仓内业务，那么复杂性就更加不言而喻了。

起初做系统时，为了尝鲜用DDD领域驱动方式，由于个人是刚接触这类业务，对此WMS领域不是非常熟悉，只是按DDD的要义，把概念照搬进来，实体、值对象、仓储、工厂、适配器、基础设置层、事件驱动、把当时CQRS读写分离也照搬了过来，使用六边形架构，各种概念，完全没有考虑到开发人员水平，由于没有一个模型引导，各种适配器、事件、实体满天飞，造成程序难以维护，几乎接近遗留代码边缘。而最初引入DDD的我，由于业务迭代快速，开发人员BUG需要补锅，各种会议，根本没时间打理；代码深陷其中。

原意是高内聚低耦合，程序可维护复用，结果别说复用，连读懂都难，偶然机会在项目外，新创建一个清理数据程序，脱离了原有技术栈，感觉一切都清净了，就好像离开了喧嚣的城市，去到一个风景优美的地方，可以自由使用各种新技术，不怕影响原有项目，更开心的是脱离了原有的模式，为什么会有这样的感觉呢？因为在解决清理数据程序时，我找到了最适合的技术，以最轻松的方式实现，如果用原来的系统，整个项目都统一风格，在你团里面感觉透不过气；

之后发现微服务非常适合，因为随着业务发展，系统在解决业务问题时不是一种架构或者模式能搞定的，即使能搞定，也不是最适合的，这时候拆分微服务，用不同的技术栈解决特定的领域问题，‘是非常清爽，而且问题得到简化，简化在哪里呢，领域问题可能还是很复杂，但微服务能够将我们从大块头解放出来，是我们能够对遗留代码进行重构而不怕影响全局，大块头混乱的代码局限了开发人员思维；

当把业务模块从大块头拆解出来后，发现可以使用不同的架构，使用更新的技术栈，技术的发展得到了解放，技术的进步使开发效率大有提升；

以往使用一个解决方案实现全套业务，那只能是最标准化软件，缓慢只有小改动优化的项目，但随着互联网快速发展，市场更新快速，这种软件不太符合社会发展，微服务才是时代的促成物。

DDD是没错的，对于行业业务积累，深刻的认识，将多次迭代形成的东西提炼出来，形成领域模型是比较适合的，但不适合于所有领域问题的解决，市场不断地在跑，很多领域问题都是新问题，如果用DDD一条路走到黑，就会造成效率迟缓，从敏捷开发的角度，用适合的架构开发适合的系统才是高效率的做法，以往照搬高大上的概念的做法，在很大程度上是在南辕北辙，但就像秦始皇练神仙不老药，所做的实验，留下了大量有价值的实验结果，时至今日也是很有用的，在使用DDD、CQRS开发后，发现转型微服务是相当舒服的，如果还是用数据脚本的方式开发，估计微服务转型就困难了。