常见的工程分四层。规定了每一层做什么。这没问题。但是我们常看到一个业务场景里有各种helper,这些helper有轻有重。我们甚至不知道一个下单流程会有多少helper。我们更难知道这些helper的职责是什么。常听说，helper是用来做一些非主业务流程事。而每个人对主业务流程的定义不同，导致一旦觉得代码不该写在service里，就开一个helper。甚至每一层都有helper。与此类似的还有xxbuilder,xxsuport。你可以预见，一个业务的每一层都有无数个class相互交织缠绕。这种现象我称为业务代码同层泛滥。
另外我们还常见一个param从最上层的适配层一直传到最底层的dao层。这个param承担了四层的参数传递的职责。第一层需要9个参数，第二层需要6，第三层需要17。那么这个param的参数数量就会无限膨胀。这种现象我称为胆大妄为的参数肆意膨胀
你一定还见过，重复的业务代码，不知其意的名，又臭又长的代码。程序员最大的痛苦其实不源于业务多变，而是前辈们遗留下神鬼画符。
使用规范可以解决以上问题。但是没有，没有任何一家公司的规范能起到效果。如今看来只有DDD这套经过十几年完善优化的规范，才是最完美的。 没错，DDD是一种编程规范。比如它的元模型就定义了各个模型的职责。DDD也是一种编程思想，是对编程六大法则的拓展。其最核心目的依然是高内聚低耦合。DDD又是一种框架，还是一种开发流程。 DDD很开放，可以任意使用它的某一部分，来解决开发中遇到的问题。
