DDD（Domain-Driven Design 领域驱动设计）是由Eric Evans最先提出,目前也有十多年的历史了，一直处于不愠不火的状态，短短几年云计算，大数据和AI各种框架，概念推出就得到各大科技公司的大力支持，随着互联网业务的规模越来越大，为了快速响应需求，微服务快速崛起解决了一些问题。但渐渐我们发现，技术的快速发展只是解决了一部分问题，业务的复杂性带来的架构挑战单纯从技术层面是解决不了的。
微服务从业务角度上看，实质是对业务领域进行了划分，加上DevOps，以对业务快速响应。微服务的成功也使我们思考业务建模的重要性。以前架构师拿到需求时，很多时候都是通过经验（by experience）来进行业务建模，映射到数据模型上，得到实体关系后再映射到类图上，业务活动抽象成一个个时序逻辑，从而翻译成代码。是的，在信息化不高，需求变化不快的企业应用里面，是一条可行的道路。
互联网的渗透到社会生活的各个领域后，我们渐渐发现，这套路走不顺了，如果业务建表不当，可能带来的是架构为了适应业务不断地妥协和腐化，从而带来巨大的维护成本。这里，需要从业务的凭经验设计，寻找更好的设计思想来解决越来越复杂业务问题。DDD也渐渐又重新回到人们的视线里面。
我曾经历一家初创的公司，它的信息化系统是通过VB+SQLServer的一堆存储过程实现的。各种物流流程就是业务表和SQL。我进去时，正当它转型使用流行的Java开始重构各类应用系统。使用流行的SSH，各类配置文件让人头大，能把环境搭建起来跑通就谢天谢地了。同样，数据库也是我们的中心，各种业务首先想到怎么建表，没人会想什么DDD，也没听说过。后来，进入了互联网，快速的业务迭代，渐渐开始做业务设计，架构设计。无意中接触了DDD的概念，感觉像很难理解。什么限界上下文，聚合根等，与传统的软件语言格格不入，我判断它看起来很美，却基本无法落地。要让团队成员理解这些概念，很难。后来就没深入了解了。
随着微服务技术体系的成熟，从容器化到k8s,从DevOps到NoOps，从serverful到serverless,云计算领域越来越细化，但为什么还会面临软件维护成本并没有和技术进步带来的好处成反比呢。当重新思考这个问题时，回顾过去参加过的各类体系统开发设计，会发现很多时候注重了技术架构但忽略了它真正服务的对象，业务。真正好的架构应该是适应业务发展的。那业务应该怎么通过建模，映射到技术架构上呢。DDD是一套完整的业务建模理论，我渐渐开始关注DDD的发展。
总结一下，我们面临的问题是，业务规模的增长带来结构变化的复杂度增大，我们需要快速响应业务变化的能力，而DDD提供业务领域设计建模型的一套方法，从凭经验设计(by experience)到理论引导，一套稳定的从业务至代码模型的解决方案。
