一线开发理解领域驱动设计(DDD)

前言: DDD与以前所有的开发思想都不一样。它通过从顶向下,不断迭代,不断分解领域模型,使得开发过程更人性化,通过全程与客户沟通形成满足实际需求的,健壮的软件

前言:

DDD与以前所有的开发思想都不一样。它通过从顶向下,不断迭代,不断分解领域模型,使得开发过程更人性化,通过全程与客户沟通形成满足实际需求的,健壮的软件。

 

我们学习使用DDD最大的阻碍就是与自己的旧的习惯(三层架构)的斗争。

要使用这种方式,还要掌握与此配套的技术。例如:Code First,CQRS

 

总体上的架构:

 

 

1、  领域驱动设计是什么?

是将软件开发过程中的分析与设计步骤统一处理的一种开发思想。

 

群友曾讨论过“能否用C做领域驱动?”。我想这并不是能不能的问题,而是合不合适的问题。就像好,夏天穿棉袄一样,穿是可以,但你非常不爽的。

 

强类型的面向对象开发方式,更适合描述领域模型。

 

2、   领域驱动设计的一般性流程。

 (1),通过与用户沟通或其它资料,建立领域模型。

(2),进一步沟通,获取深层需求。并按需要对领域模型进行分解出实体类。

(3),不断迭代第二步,直到业务不能分解

(4)将实体类通过Code First,持久化数据。

 

 

 

 

3、  老程序员应该注意的问题?

老程序员是指用擅长三层架构开发人员。

1,如何区分领域模型类,Facade

领域模型类不是由模型层的实体类及服务层的服务类封装成的Facade类。做久了三层架构的开发人员会按照对领域模型的理解,不由自主的惯性的,把模型层及服务层的相关逻辑拼成一个聚合根。我说这个层不是Domain层,而是 Facade层。为什么呢?方向不对!领域模型层是分析设计出来的,其作用是为下一次迭代作准备的,是由高层向底层分解的过程。而上面的作法则是向上封装逻辑的过程,用来好看的。

 

2,要以业务为核心,而非数据持久化

DDD是从外向内,迭代发现需求,达成业务目标过程。运用Code First技术,使得DDD只专注于为客户需求建模并实现逻辑。数据只是这个过程中的产物罢了。DDD对待数据持久化,采用外包的形式,转让给Entity Framework 或 NHibernet等ORM工具。

对照三层架构,不难看出。两种开发模式截然相反,DDD是由高层向底层,不断分解业务。而三层架构则由底层向高层不断Facade封装逻辑。

判断一个项目是否是DDD,最简单的方式就是。是先业务建模,还是数据建模。