按照一般的项目管理过程，“需求”之后是“分析”，那么在分析阶段对应的技术流程又是哪个？如何将需求阶段和分析阶段联系起来呢？答案就是“领域模型”
什么是“领域模型”呢？只要抓住“领域（Domain）”二字就可以理解，也就是说领域模型是帮助我们理解相关领域知识的模型。
进一步来问：为什么需要领域模型？前面不是有“用例模型”吗，看起来用例模型好像就是描述相关领域知识的，是否完成用例模型就可以进行设计了？
如果你曾经写过用例文档，或者仔细看过用例文档，那么你肯定知道“用例”本身和“面向对象”、“类”这些都没有关系，用例就是纯自然的语言（比如英语、汉语）写的，因为用例实际上由客户口述给我们、然后由我们形成文档化的用例文档，客户才不管我们是什么面向对象还是面向过程还是阿猫阿狗的。
因此，单纯从用例来看，是没有类的概念的，无法完成从自然语言到面向对象语言的转换。但是，既然我们已经完成了用例模型，那么就必须基于用例模型进行分析(否则用例模型岂不是白做了)，而“领域模型”就是自然语言向面向对象语言的一座桥梁。
让我们来看看“领域模型”阶段我们要做什么、该怎么做。其实很简单，简单概括就是“找名词”，分为四个步骤：（1）找出用例模型中的名词，（2）然后识别这些名词本身的相关信息，（3）以及名词之间的相互关联关系，（4）用UML画出领域模型。
我们来看在“用例模型”章节中的POST用例如何得出领域模型。
第一步：找出用例模型中的名词
原有用例如下，用蓝色加黑标出名词（重复的就不标了）：
1）顾客携带商品到收银台；
2）收银员扫描商品条形码；
3）系统根据条形码获取并显示商品信息；
4）收银员重复2~3步，直到所有商品扫描完毕；
5）系统计算商品总额；
。。。。。。。。。。。。。。。。。。。。
n）系统打出商品清单，完成交易。
这个用例中的名词有“顾客”、“商品”、“收银台”、“收银员”、“商品条形码”、“系统”、“商品信息”、“商品总额”、“商品清单”、“交易”。稍加整理：
1）“顾客”、“收银员”是系统的外部对象，不需要我们进行设计，但这些对象要和系统进行交互；
2）“商品”、“商品条形码”、“商品信息”、“商品总额”、“商品清单”、“交易”是领域对象，但“商品条形码”、“商品信息”可以算作“商品”的属性、“商品总额”可以算作“交易”的属性，最后从这个用例总结出来的领域对象有“商品”、“商品清单”、“交易”三个。
第二步：识别这些名词本身的相关信息
一个对象的属性可能分布在多个用例中，因此可以通过迭代不断的完善一个对象的属性，大家可以看到，我们在第一步中的样例就已经分析了一部分了：“商品条形码”、“商品信息”可以算作“商品”的属性。
对象除了属性外，还有一些约束或者限制，这些在用例中可能有，也可能没有，这就需要分析人员来发现了。比如说交易金额必须大于0.1元小于99999元这种约束，用例中不一定会体现，可能需要分析人员向客户咨询。
第三步：识别对象间的关系
面向对象设计就是依靠对象间的互相协作来配合完成相应的功能，因此识别出对象和对象本身的属性外，还要识别对象间的关系，例如1对多、1对1、依赖等，详细的各种关系可以参考UML的标准定义。
我们以第一步识别的三个对象为例：“商品清单”包含多个“商品”、一次“交易”对应一个“商品清单”、一个“商品”只能属于一个“交易”等。
第四步：画出领域模型UML图
UML这里就不啰嗦了，我们结合前三步的分析，画出这个样例的UML领域模型图：
（由于CSDN关闭了图片上传功能，因此无法贴出，大家可以根据前三步自己画一个）
大家可以看到，经过“领域模型”的分析后，已经完成了自然语言到面向对象语言的初步转化了，领域对象已经识别出来，面向对象已经初具雏形。
需要提醒的是：领域模型过程中识别出来的对象和具体的语言无关，也没有方法。换句话说，public、private、函数这些面向对象的属性在领域模型阶段不需要分析出来。