浅谈-为什么团队使用DDD驱动这么难？

前言：

2022-12-22日 下午，晴

一位财务产品线的后端开发负责人找到我，和我讨论关于DDD领域驱动设计的实践层面问题。

原因：

居中他找到我和我说最近项目空了，想重新把DDD驱动搞起来，改造目前项目维护困难的问题。 现在的项目采用的架构较老，数据库表有两百多张，但实际业务没有那么复杂，之前的项目维护人员换了一批又一批了，线上出点问题就要花很长时间排查，做一个很简单的需求也是两周之后才能上线。

问题：

这个同学之前也聊过关于DDD的理论部分，但是这两天趁着不忙，他开始在项目上动刀子了，扩展新建了DDD的模块 并以一个旧需求为领域去尝试拆分填充DDD的框架，这是他遇到的问题：

1、目前遇到领域对象的事件如果有子域的关联的话，它不知道该如何处理？

2、对于仓储层（Repository）上层调用的拆分感觉不是很符合面向对象，老项目如何做过渡？

3、对于CQRS的查询分离没有明确定义。

分析：

对于他的问题，我基本了解的他的思路并问了相关问题：

1、DDD的建设前提是业务的聚合，这是需要开发积累的细分文档和产品下功夫去啃透的，如果这个做不到，DDD的建设半途会遇到很多相同的问题需要处理，现在团队对于DDD意见如何？是否愿意去学习去补充？ 结论：尚不明确，目前进度文档由于维护人员迭代导致设计文档极度缺失。

2、一切设计的前提都需要考虑未来，这个产品预计迭代多长时间？也需要考虑项目的PV和UV和开发成本的投入，老板对于这个项目是什么态度？这个产品使用者自己的意见？ 结论：投入半年时间，产品和QA亦然。

3、开发团队对于DDD的熟悉程度，是否参与过设计或参与过编码，项目负责人是否认可这个投入成本带来的项目？ 结论：开发团队几乎零经验，且大家都不是很想去参加设计，更别说写文档和写代码了，项目负责人也是持保留意见。

结论：

分析了他的代码之后，我给出了以下几点意见：

1、业务领域之间的划分，以业务领域本身事件去看其实他是有主动和被动的事件，且关联的实现应通过抽象工厂去解耦，领域事件中的子领域事件应有调用方去通过工厂获取子领域中的被动事件响应。

2、DDD的仓储层（Repository）和C#曾经的三层架构中（Repository）的很像，这一点他get到我的意思了，最终的产物还是抽象，至于上层调用的拆分，更应该按照拆分出来的（Repository）中的对象去分步处理，而老项目的过渡，我和他沟通之后建议先不用更改老项目，直接对老项目的Mybatis做一层上层的基础设施层（infrastructure）的封装。

3、考虑到项目的发展，我明确建议改造的项目对于CQRS不需要过度的依赖，否则拆来拆去都是冗余的代码，关键这些代码你还不知道往哪里去放，放在任何地方都是对DDD的破坏。

其他：

其实聊过之后发现，对于DDD的认识只是纸上谈兵，各种前提条件都没有满足，除非他一个人埋头苦干，矜矜业业的钻研下去，但是大家都是说利益成本的，这个对于开发团队来说的确是好事，但是负责人对于团队不够熟悉，无法掌握团队的工作意向，这个时候喊着口号说要打仗，士气其实很难提高，不如扎扎实实把文档先补充，不断的磨合说服产品团队去对老的需求进行重新梳理，培养团队的DDD设计思想，这样才能稳扎稳打，步步为营。

很可惜的是，国内很多团队都是只看利益，忽略长期投资，开发人员也是只看眼前自己的能少干一点轻松一点，这是目前我遇到这个团队的对于DDD项目改造的困难，发出来和大家分享，你们是否也遇到过这种情况呢？