领域驱动设计(DDD)靠谱吗?

怎么感觉在国内没什么人用啊

由于公司领导的要求,所有的软件开发都要将DDD作为指导思想,并且要接受敏捷的思想;"迫不得已"下拜读了《实现领域驱动设计》这本书,将会在公司的内部系统上全面实践DDD。

DDD把领域模型的重要性提高到了数据模型之上,在传统的MVC分层架构下。我们将项目结构分为Controller,Service,DAO 这三个主要的层,所有的业务逻辑都在Service中体现,而我们的实体类Entity却只是充当一个与数据库做ORM映射的数据容器而已,它并没有反映出模型的业务价值。所以又把这种模型称为“贫血模型”。“贫血模型”有什么坏处呢?
在我们的代码中将会到处看到各种的setter方法和各种各样的参数校验的代码,尤其是在Service层,但是这些代码它并没有反映出它的业务价值。这就是事务脚本的架构下,所呈现出来的弊端,这种模式下认为数据模型优先,所以会导致开发人员和产品经理在讨论问题的时候,完全是从两个角度在思考问题。开发人员听到需求后,脑袋里想的并不是如何反应出业务的价值,而是考虑的是数据库表怎么设计,字段该怎么加这些问题。

所以DDD中提出了通用语言这么一个概念,并且基本将通用语言的概念贯穿于整个落地的过程。这样会大大的减少成员之间的沟通成本(前提是大家都从心里接受了DDD)。

为什么DDD难以落地呢?

第一,国内关于DDD的最佳实践还是太少了,除了知名的几个大厂以外很少看到有关于DDD的落地实践。这里附上美团的DDD实践,美团领域驱动设计;最佳实践太少意味着,我们可以参考的资料就少,承担的项目失败的风险就大。

第二,DDD中出现了很多的概念和术语,比如 聚合根,值对象,六边形架构,CQRS(命令和查询职责分离),事件驱动等等概念。很多人看到了这么多概念的时候,心中就开始打退堂鼓了。

第三,DDD需要我们在领域建模花费很多的时间和精力,而且还可能导致付出和收益不成正比的情况。因为在界限上下文的划分上是非常考验架构师的业务水平。如果没有将业务模型很好的识别出来,那么可能很快模型就会在迭代的过程中腐败掉了。

评论

  1. 只依赖其中的某些思想或者部分框架 感觉还行
  2. 其实团队也很重要
  3. 团队水平要求高。要应用DDD必须持续迭代重构完善领域模型,否则模型会腐化,越来越难用,最终又回到之前的开发模式。就这2点就拦下了绝大多数项目的实施。 不过其中的思想,还是很值得开发借鉴和思考的,值得学习。

参考:https://www.zhihu.com/question/328870859

你可能感兴趣的:(Java设计模式,架构设计等思想,项目管理维护,DDD)