对于架构，我一直强调对系统复杂性的应对。我曾经在十月份的一个会议上分享过《如何应对架构的高复杂度》，内容其实来源于我对复杂系统思考所撰写的一篇文章。我从理解力与预测能力两个角度剖析软件系统的复杂度。这个思考角度实际来自Jurgen Appelo对复杂系统理论的阐释。Jurgen Appelo将Complicated与Complex分别放在理解力与预测能力两个迥然不同的维度。Complicated与Simple（简单）相对，意指非常难以理解，而Complex则介于Ordered（有序的）与Chaotic（混沌的）之间，认为在某种程度上可以预测，但会有很多出乎意料的事情发生。如下图所示：
系统的规模与结构会干扰我们对系统的理解，而需求的变化则是我们无法预测的。那么，微服务是怎么应对系统复杂度的呢？核心思想是“分而治之”，它从系统规模着手，将一个大的系统拆分为一个个细粒度的服务。即使不考虑拆分的合理性，我们也可以看到它虽然控制了规模带来的复杂度，却加强了结构的复杂性。
个人认为，微服务对simplicity的保证，实则是将业务复杂度转移到了技术复杂度。显而易见，每个微服务的业务是非常简单的，代码易于理解和维护，也可以非常容易地进化乃至于替换。当我们需要开发和维护多个微服务时，如何管理和监控服务，如何梳理服务之间的通信，如何保证数据的一致性（最终一致性），都来自技术层面的挑战。
这种复杂度的转移为何能得到多数人的认同？针对IT人员，它其实基于两个前提：
业务是不可控的，技术却相对可控：相对于技术，业务对变化更加敏感，我们也无法正确地预测业务的变化
技术的复杂性可以通过分工来解决：多数应用开发公司可以重用微服务的平台、框架或工具，然后集中精力来对付业务；降低了业务复杂度，就等同于降低了整个系统的复杂度
DDD的未来在接受会议主办方的采访时，希望我能给DDD打call。那么DDD重要吗？非常重要，但它确实不是“银弹”。正如前面所述，DDD其实一直在生长。由于没有任何一家商业化公司推动DDD，它反而没有受到利益关系的干扰，虽然生长缓慢，但却健康。DDD以“领域”为核心，只要软件系统仍然还在处理“领域”，理论上DDD就有其生存的空间。如果我们不把DDD具象化（正如前面所说），它就可以成为一个不错的“框”，凡是和“领域”相关的理论、方法、实践与模式，都可以往这个框里塞。
倘若能一直保持DDD的开放性，保持DDD的独立性，我觉得在未来的五年乃至十年，DDD仍将焕发生命力，只是它的面貌会更加多姿多彩，甚至超过Eric Evans对DDD的原初定义。毕竟，软件系统的核心只有两个：领域和算法。也许，只有到了AI算法能把领域开发的职责都能揽过去，DDD才不会存在了，因为那时候已经没有了领域，只剩下了算法。