评估总结

维度 MVC DDD
API接口清晰度 含混不清 接口清晰可读
数据校验、错误处理 校验逻辑分布多个地方，大量重复代码 校验逻辑内聚，在接口边界外完成
业务代码的清晰度 校验代码，胶水代码，业务逻辑混杂 无胶水代码，业务逻辑清晰可读
测试复杂度 N _M _P N + M + P
可维护性 差 高
可扩展性 差 高

DDD优点

  • 由于对业务进行了专业的领域划分，使得业务逻辑更加清晰，正确的业务归类有利于后续业务扩展。
  • 领域对象面向对象编程，使得代码工程更加高内聚。将业务逻辑分散到各个领域对象中，使得对象外部代码更加精减。
  • 只需要插入事件和命令到固化的数据库，速度比通过索引UPDATE快，尤其对于一些Write-Ahead-Loging的NOSQL数据库，写入速度会非常快
  • 全异步的事件驱动，相对于传统的同步数据库请求，改进明显，数据库不再是瓶颈
  • 可以随时回溯到某个状态，查看用户的一系列操作，容易查找问题

  • 所记录的事件可以用来进行BI分析，挖掘用户的隐藏属性，操作习惯，进行一些有价值的预测。

    DDD缺点

  • 面向对象编程，使得业务逻辑分散到各个领域模型中，对于后续接手且没有完备的文档或代码注释的人来说，难以快速了解到整体业务逻辑。

  • 领域驱动设计中，领域模型是面向对象设计，自然持久层实现就是JPA标准。而JPA对于复杂查询，设计不好容易有性能问题。对于简单系统，JPA是友好的选择，但复杂的系统实现就不见得了，而领域驱动设计就是针对复杂系统而言的，所以在数据持久化方面，如果选择JPA，则需要面临JPA的问题，如果选择MyBatis这种SQL封装的框架的话，则需要在模型转换上多花些处理。