专栏写到这里，不知道你对DDD的理解是什么样的？本专栏从一个最具体的转账功能说起，以代码推演的方式引出了DDD的三层架构，相信由此延伸出来的DDD的概念都能够帮你对于DDD有个比较清晰的概念。DDD并不是凭空产生的，他只是对代码结构进行推演的过程中沉淀下来的一种方法论。但是当DDD从一个具体的技术架构往更上层的微服务架构以及中台战略延伸的过程中，专栏又提到DDD又要不断的进行变化。这个时候你是不是又会觉得DDD有点虚无缥缈了？专栏前面好几次提到，DDD是面向变化的一种软件设计方式，DDD到底是如何来把控未知的系统变化？这一章节，我们将对DDD从见山是山，见山不是山的第二重境界进入到见山还是山的理解。
软件进化困难的根源 在实际项目中，很多软件团队都发现，要对一个已经成型的系统做一次技术升级，是一件非常困难的事情。尤其对于已经运行了很多年的系统，哪怕只是一个小小的组件版本升级，都是非常痛苦的。例如，在大概十年前，业界最常用的ORM框架是Hibernate，而到了现代，轻量级的MyBatis逐渐成为了主流。但是，如果要将一个使用Hibernate的项目全部升级为MyBaits，需要对所有业务进行一一梳理。这个工作量，在很多运行了多年的大型项目中是不可想象的。为什么技术升级会那么费劲呢？究其原因，是因为在系统设计开发过程当中，业务代码大量的依赖于底层的技术框架，形成了耦合。
所以，解决软件进化困难的根本方法，就在于解耦。在业务代码与底层技术之间进行解耦。而解耦的方式就是通过建立"接口层"。但是并不是随意的添加接口，就可以将业务与底层技术解耦。这里可以回顾一下专栏第二
