领域模型（转）

按照通常的项目管理过程，“需求”以后是“分析”，那么在分析阶段对应的技术流程又是哪一个？如何将需求阶段和分析阶段联系起来呢？答案就是“领域模型”

什么是“领域模型”呢？只要抓住“领域（Domain）”二字就能够理解，也就是说领域模型是帮助咱们理解相关领域知识的模型。

进一步来问：为何须要领域模型？前面不是有“用例模型”吗，看起来用例模型好像就是描述相关领域知识的，是否完成用例模型就能够进行设计了？

若是你曾经写过用例文档，或者仔细看过用例文档，那么你确定知道“用例”自己和“面向对象”、“类”这些都没有关系，用例就是纯天然的语言（好比英语、汉语）写的，由于用例实际上由客户口述给咱们、而后由咱们造成文档化的用例文档，客户才无论咱们是什么面向对象仍是面向过程仍是阿猫阿狗的。

所以，单纯从用例来看，是没有类的概念的，没法完成从天然语言到面向对象语言的转换。可是，既然咱们已经完成了用例模型，那么就必须基于用例模型进行分析(不然用例模型岂不是白作了)，而“领域模型”就是天然语言向面向对象语言的一座桥梁。

让咱们来看看“领域模型”阶段咱们要作什么、该怎么作。其实很简单，简单归纳就是“找名词”，分为四个步骤：（1）找出用例模型中的名词，（2）而后识别这些名词自己的相关信息，（3）以及名词之间的相互关联关系，（4）用UML画出领域模型。

咱们来看在“用例模型”章节中的POST用例如何得出领域模型。

第一步：找出用例模型中的名词

原有用例以下，用蓝色加黑标出名词（重复的就不标了）：

1）顾客携带商品到收银台；

2）收银员扫描商品条形码；

3）系统根据条形码获取并显示商品信息；

4）收银员重复2~3步，直到全部商品扫描完毕；

5）系统计算商品总额；

。。。。。。。。。。。。。。。。。。。。

n）系统打出商品清单，完成交易。

这个用例中的名词有“顾客”、“商品”、“收银台”、“收银员”、“商品条形码”、“系统”、“商品信息”、“商品总额”、“商品清单”、“交易”。稍加整理：

1）“顾客”、“收银员”是系统的外部对象，不须要咱们进行设计，但这些对象要和系统进行交互；

2）“商品”、“商品条形码”、“商品信息”、“商品总额”、“商品清单”、“交易”是领域对象，但“商品条形码”、“商品信息”能够算做“商品”的属性、“商品总额”能够算做“交易”的属性，最后从这个用例总结出来的领域对象有“商品”、“商品清单”、“交易”三个。

第二步：识别这些名词自己的相关信息

一个对象的属性可能分布在多个用例中，所以能够经过迭代不断的完善一个对象的属性，你们能够看到，咱们在第一步中的样例就已经分析了一部分了：“商品条形码”、“商品信息”能够算做“商品”的属性。

对象除了属性外，还有一些约束或者限制，这些在用例中可能有，也可能没有，这就须要分析人员来发现了。好比说交易金额必须大于0.1元小于99999元这种约束，用例中不必定会体现，可能须要分析人员向客户咨询。

第三步：识别对象间的关系

面向对象设计就是依靠对象间的互相协做来配合完成相应的功能，所以识别出对象和对象自己的属性外，还要识别对象间的关系，例如1对多、1对一、依赖等，详细的各类关系能够参考UML的标准定义。

咱们以第一步识别的三个对象为例：“商品清单”包含多个“商品”、一次“交易”对应一个“商品清单”、一个“商品”只能属于一个“交易”等。

第四步：画出领域模型UML图

UML这里就不啰嗦了，咱们结合前三步的分析，画出这个样例的UML领域模型图：

 

你们能够看到，通过“领域模型”的分析后，已经完成了天然语言到面向对象语言的初步转化了，领域对象已经识别出来，面向对象已经初具雏形。

须要提醒的是：领域模型过程当中识别出来的对象和具体的语言无关，也没有方法。换句话说，public、private、函数这些面向对象的属性在领域模型阶段不须要分析出来。

转自：http://www.cnblogs.com/ppgeneve/p/5089113.html