最近在思考DDD的落地情况（笔者刚去了一家新公司，总会比较一下），似乎DDD是一个很好的东西，但随着学习和实践的深入，越来越发现，在当下的很多技术团队里，DDD推行起来还是比较困难的。所以将一些坑和心得记录如下：

流程为王，建模是什么？ 这似乎是目前很多技术团队的通病，遇到一个产品或需求，很多经验老道的上来就是梳理流程（这已经算比较不错的，有的是上来就写代码），一个个流程图，泳道，时序 画的贼溜。建模？没有建模，只有数据库表，库表的设立也与现实的实体一一对应，能稍有提炼的也是教课书里面反复嚼烂的：角色，权限等。 模型的抽象完全没有任何思考。所以DDD中的领域划分，限界上下文与领域的关系，别说什么核心域，通用域了，就是一个简单的系统里面域是什么，大部分开发人员并没有思考和分析，所以这些对于很多技术人员有如一座不可逾越的大山。

思维转换的难度，在目前大部分开发人员里面，很多都是浅度开发，即你给我产品原型，我通过框架实现增删改查。不管是所谓的技术管理者还是架构师，开发任务的分配也是依据产品的原型图来进行划分的（其实这也间接的导致了产品经理低水平化）。 拿到原型就开始写代码，一个交互对应一个三层类，这样简单的机械化的编码方式，不是不好，产品如果很简单，这样的项目反而直观简单，但一旦遇到复杂逻辑的项目，就错综复杂，维护起来也是叫苦连天，所以又直接导致了另一个程序员的坏毛病，一个运行正常的系统，往往因为换了技术支撑团队，而需要进行所谓的重构。

数据库依赖症，可能是老一辈程序员因为语言和环境的问题，所以从老到新或多或少都会将数据库摆在整个系统的核心位置（注意不是数据，不过在很多人的观点里面，数据和数据库是等同的）。所以一切思考的目标都是为了适应数据库的设计，所以一切编程结果你也可以看成就是一系列的 事务操作脚本，所以用面向对象的语言写出面向过程的代码，一点也不奇怪。

阻抗的沟壑，关系型数据库诞生的目的就是为了方便查询，但真实的世界的构成和运行，其实都没有这个目标，至少主要目标不是这样的。这样就诞生了两种不同的思维方式，导致很多时候系统的设计和开发往往有相当一部分逻辑是来处理这两种不同的思维方式的转换（其实很真正的业务一点关系也没有。。。。。）。工程的浪费，甚至导致效率的浪费。当然也有思维方式的改变的风险和禁锢。

重视程度不够，其实大部分时候，别说老板了，就是技术团队自己对于设计和文档都重视不够，项目一上线，没有问题，皆大欢喜，那个时候只有喜悦和庆功，你这个时候提出来，可能之前的设计与代码对不上，需求有变动的时候，只改了代码，而没有改正相应的设计，你这不是太不懂得场合了吗？所以设计分析工作在很多很多团队不是重要的工作（除非是一些合同约定），即便是需要交付，那么 文档和实现的不一致，这个谁会关心了，谁会去检查了？所以就这样吧。