一线开发理解领域驱动设计（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，最简单的方式就是。是先业务建模，还是数据建模。