DDD模型落地的几点思考

DDD模型落地难的问题

第一次听到“DDD模型难落地”，是刚转到咨询的第一个年会上。我当时内心的OS是“DDD模型难落地？怎么会？我都落地了3年多了，难道我一直都是在做假的DDD？”。然而，很快，我就啪啪打脸了。参加完年会，我的第一个基于DDD重构的咨询，卡在了DDD战术设计落地上。

那么为什么DDD模型在客户那儿比在我们自己更难落地？
做DDD建模的目的不同

• 为了更好的支持业务
  我们团队建模主要是为了让模型能够更适用现有的业务。没有最好的模型，只有最适合的模型。只要将所有业务带入到模型中去验证能符合，就是好模型。
• 为了获得一个更好的模型
  客户做DDD建模，基本都是为了为了获得一个更好的模型。为了获得一个更好，更全的模型，往往会引入未来一段时间内的业务需求，同时引入多方人员参与建模。这个过程建出来的模型可能会出现对当前的业务支持没有那么好，而是一个更适合“未来”的模型。因此，当想把现有模型进行修改时，可能会出现不适用的情况。

做DDD模型的改造方式不同

• 小规模/迭代式落地
  当模型建好以后，我们团队会将现有模型和原有模型进行比对。然后制定改造计划，对现有模型一步一步的改造成我们期望的模型。然后将各个步骤拆分成技术卡，分散到各个迭代中去。
• 大规模/一次性落地
  当模型建好以后，对比现有模型和原有模型后，客户一般会有2种方式进行改造
  • 拉个独立的分支进行修改，修改完合并回原来的分支。然而，合并回原分支的时候，往往需要解决过多的冲突。最终可能导致放弃。
  • 直接在原有分支进行修改，改完模型后，需要花很长时间去修复坏了的功能，导致整个应用在很长一段时间不可用。

做DDD建模的规模不同

• 轻量级
  我们团队建模的时候，基本都是轻量级建模。每个迭代（2周一个迭代）开始的时候，基于新增的需求，我们会简单的做一次模型匹配，看现有的模型是不是还能满足需求。如果是微调，模型修改会通过Code Review的时候，跟大家进行同步。如果需要大改或者比较复杂，我们会让2-3个核心人员（开发，测试，业务）进行DDD模型设计，并将结果同步给大家，并做进一步的答疑（大约占用大计1-2小时的时间）。整个过程占用的时间不会太多，不会影响项目交付的进度，每次模型修改不会太大，全员信息同步的效率高。
• 重量级
  客户的建模的时候，基本都是重量级建模，客户基本上会把现有系统的整个/大部分功能进行梳理，然后对整个/大部分功能进行建模，整个过程耗费时间久，参与人员多，且基本都是脱产建模。常常会遇到在建模的过程中，某些人员只负责部分模块的开发和设计，对其他模块不了解，从而容易跑神，造成同步效率低。同时，大家都脱产去建模，项目交付压力会很大。

DDD模型如何正确落地

• 轻量级建模
  以迭代为周期，每个迭代进行增量的建模，降低建模成本。
• 小步改造
  不要想着花一段时间专门改模型，改架构。单纯的做技术卡是没有业务价值的，将架构改造，模型重构的事情分成多个小步骤，融入到每个迭代中，一步一步的做。
• 没有银弹，60分就可以了
  不要想着建出一个很好的模型，再也不用改了。随着时间的变化，业务形态的变化，我们的模型一定会跟着变化的，所以，只要能满足现有业务的模型就是好的模型。
• 工具可视化模型
  通过工具可视化展示代码模型，帮助大家直观的进行模型分析和模型守护。