1.前言
以当前迭代中所要设计的需求为界，创建领域模型的步骤：
1.寻找概念类
2.将其绘制为UML类图中的类
3.添加关联和属性
2.如何寻找概念类
寻找概念类有如下几种方法：
- 重用和修改现有的模型
许多常见领域都存在已发布的、绘制精细的领域模型和数据模型
- 使用分类列表
业务交易 -》 交易项目 -》 与交易项目相关的产品或服务 -》 交易记录何处？。。。。
- 通过识别名词短语寻找概念类
在对领域的文本型描述中识别名词和名词短语，将其作为候选的概念类或属性
3.绘制UML类图中的类
- 规则1：敏捷建模--绘制类图的草图
- 规则2：敏捷建模--如果有人在新发现时想要维护和更新模型，则使用UML工具画类图是可以的
- 规则3：如果某个类在领域模型中没有意义，则排除它
- 规则4：使用领域术语来绘制类图
- 规则5：对于软件领域与自然领域无相似之处，则对常见的非OO设计进行回顾，汲取领域专家使用的核心词汇和概念
- 规则6：创建领域模型最常见错误是把应该是概念类的事物表示为属性
- 规则7：何时需要使用描述类建模
下面的情况下需要增加描述类：
1.在任何商品或服务之外，需要有关商品或服务的描述；
2.删除所描绘事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误的与所删除的事物关联起来；
3.减少冗余或重复信息
4. 关联和属性
4.1 关联
关联是类之间的关系，表示有意义和值得关注的连接
- 何时表示关联
领域模型从概念角度出发的，是否需要记录关联，基于现实世界的需要，不是基于软件的需要
- 避免增加大量关联
会产生视觉干扰，要谨慎增加关联，重点关注需要记住的关联
- UML关联表示法
关联表示为类之间的连线，冠以首字母大写的关联名称，关联的末端可包含多重性表达式，关联本质是双向的；
关联以“类名--动词短语--类名”的格式为关联命名
关联名称应该使用首字母大写的形式，因为关联表示的是实例之间链接的类元，UML中类元首字母要大写
关联的每一端称为角色
多重性定义了类A有多少个实例可以和类B的一个实例关联，值取决于我们的观察角度
两个类之间可能有多重关联
图 关联的UML表示法
- 在常见关联列表中找到关联
图 常见关联列表
4.2 属性
- 何时引入属性
当需求（例如用例）建议或暗示需要引入信息时，引入属性，例如处理销售用例中的票据含有日期和时间、店名和地址以及收银员ID等
- UML属性表示法
属性在UML类图的第二框表示，按照惯例，大部分建模者会假设属性的可见性为私有的
- 什么样的属性数据类型是合适的
大部分数据类型是简单数据类型，不应该是复杂的领域概念；把复杂领域概念建模为属性是常见的错误，而应该通过关联进行连接；
- 何时定义新的数据类型类
图 对数据类型建模的准则
- 新的数据类型类应该放到何处
可能放到类图的属性分格中；
如果是具有属性和关联的新类型，则表示为单独的概念类会提供较多信息
- 任何属性都不应该表示外键
属性不应该用于表示概念类的关系
图 不要将属性作为外键
- 对数量和单位建模
一般应该给数量和单位创建单独的类？？
5.领域模型是否正确？
所有模型都是对我们试图要理解的领域的近似，主要在特定群体中用于理解和沟通的工具，有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息
6. 迭代和进化式领域建模
- 每次迭代大概只会花费30分钟
- 迭代开发中会通过若干迭代对领域模型进行增量的演进
- 每个迭代中领域模型都会现定于之前和当前要考虑的场景
- 避免瀑布思维倾向，为完成详尽正确的领域模型进行大量的工作。
- 每次迭代的领域建模不过几个小时
- UP中的领域建模：
初始阶段不会发起领域建模
领域模型在细化阶段发起创建
图 UP制品及创建时限