DDD – domain-driven design

最近发现表达能力愈发下降,但求头脑清晰。记录一下DDD模型区别于MVC和MVVM架构的想法。

什么是DDD

DDD是领域驱动设计的缩写。在MVC分层后,继续对应持续化MVVM模型的进一步抽象。

1,把项目重点区域区分出来,作为核心领域设计和开发。可以区分为针对客户core domain部分,和领域逻辑部分。有点轻量化CRM加逻辑外展的模式,进一步抽象实现对应到持续化的模型。有利于中间件开发和维护。

2,以第一部分领域中的模型为基础模型进行进一步复杂设计,服务对象还是针对domain,可采用工厂模式或者选择器模式进行接口开发。

3,让技术人员和相对领域专家合作,迭代完成领域产品的特定逻辑和概念模型。深度定制领域功能和诉求,并提供服务接口,共享逻辑运算和模型结果。


对比MVC

MVC模式比较统一,小型项目快速开发合适。但是随着项目的扩展和壮大,MVC模式就越发显得笨重。具备很明显‘牵一发动全身’的特征。类比MFC迁移向WPF,成长型项目中,中心化设计对于前期发展帮助很大,但是需要在合适时机转型为模块驱动开发,慢慢弱化事物驱动开发方式。

代码角度:

  • 瘦实体模型:只起到数据类的作用,业务逻辑散落到service,可维护性越来越差;
  • 面向数据库表编程,而非模型编程;
  • 实体类之间的关系是复杂的网状结构,成为大泥球,牵一发而动全身,导致不敢轻易改代码;
  • service类承接的所有的业务逻辑,越来越臃肿,很容易出现几千行的service类;
  • 对外接口直接暴露实体模型,导致不必要开放内部逻辑对外暴露,就算有DTO类一般也是实体类的直接copy;
  • 外部依赖层直接从service层调用,字段转换、异常处理大量充斥在service方法中;

项目管理角度:

  • 交付效率:越来越低;
  • 稳定性差:不好测试,代码改动的影响范围不好预估;
  • 理解成本高:新成员介入成本高,长期会导致模块只有一个人最熟悉,离职成本很大;

DDD模型特点

  • 统一语言
  • 限界上下文
  • 领域、子域、支撑域
  • 聚合、实体、值对象
  • 分层:用户接口层、应用层、领域层、基础层

https://blogpic.chekuspace.com/5fKsjeq0ZqpGk7XvauObZBXrtzjMiXOpLhzJhKLUBiI.png

简单来说,DDD针对于MVC视野来看,比MVVM更具备业务抽象能力。不单纯同步看ViewModel和DataModel的统一性,更多关注领域层的聚合特点。

https://blogpic.chekuspace.com/nm2JYF5eU_NhBTjnuQzNg9SJL5ViYyHKfL_myGe5ojY.jpeg


Leave a Comment

Your email address will not be published.