连载：面向对象葵花宝典：思想、技巧与实践（23） - 领域建模三字经
看起来有点不可思议，需求阶段“白纸黑字”的用例文档，经过我们一步一步的操作，逐步就得到了“图形化”的领域模型，面向对象初具雏形。
领域建模的三字经方法：找名词、加属性、连关系。
我们接下来以一个样例看看领域模型具体如何建模。
1.1. 找名词
我们以POS机买单的用例来看看具体如何建领域模型。
首先，将用例中所有的名词挑选出来（如下用例文档中蓝色加粗的词组）：
【用例名称】
买单
【场景】
Who：顾客、收银员
Where：商店的收银台
When：营业时间
【用例描述】
1. 顾客携带选择好的商品到收银台；
（这一步没有异常）
2. 收银员逐一扫描商品条形码，系统根据条形码查询商品信息；
2.1 扫描仪坏了，必须支持手工输入条形码；
2.2 商品的条形码无法扫描，必须支持手工输入条形码；
2.3 条形码能够扫描，但查询不到信息，需要收银员和顾客沟通，放弃购买此产品
3. 扫描完毕，系统显示商品总额，收银员告诉顾客商品总额；
（这一步没有异常）
4. 顾客将钱交给收银员；
4.1 顾客的钱不够，顾客和收银员沟通，删除某商品；
4.2 顾客的钱不够，顾客和收银员沟通，删除某类商品中的一个或几个（例如买了5包烟，去掉两包）
4.3 顾客觉得某个商品价格太高，要求删除某商品；
4-A：顾客使用信用卡支付
4-A.1 信用卡支付流程（请读者自行思考完善，可以写在这里，如果太多，也可以另外写一个子用例）
4-B：顾客使用购物卡支付
4-B.1 购物卡支付流程
4-C：顾客使用会员卡积分支付
4-C.1 会员卡积分支付流程
5. 收银员清点钱数，输入收到的款额，系统给出找零的数目；
（这一步没有异常）
6. 收银员将找零的钱还给顾客，并打印小票；
7. 买单完成，顾客携带商品和小票离开；
【用例价值】
顾客买完单以后，就可以携带商品离开，而超市也将得到收入；
【约束和限制】
1. POS机必须符合国标XXX；
2. 键盘和屏幕使用中文，因为收银员都是中国人；
3. 一次买单数额不能超过99999RMB；
4. POS机要非常稳定，至少一天内不要出现故障；
名词列表：
顾客、收银员、收银台、商品、条形码、扫描仪、钱、5包烟、信用卡、会员卡、小票、买单、键盘、屏幕、中文、中国人
通过这种简单的方法，我们很轻松的就识别出了领域中的各种概念，但是还不能高兴的太早，识别领域概念的工作还没有结束，接下来我们还需要提炼。
有了前面步骤识别的名词列表后，提炼的工作就相对很简单了，只需要删除不是领域对象的名词即可。
但具体应该删除什么名词，是和不同的业务领域强相关的，并没有完全统一的标准，此时分析师的行业和领域经验起决定作用，而这也正是菜鸟和专家的区别。
以我们的收银机为例，提炼的过程如下：
1）删除“收银台”：收银台只是一个物理设备，且这个设备与我们的POS机也没有任何交互，所以不能算作领域模型中的一个概念；
2）删除“5包烟”：5包烟只是用例中举例时的一个实例，是一个具体的商品，已经包含在“商品”中了；
3）删除“中文”：“中文”只是“键盘”和“屏幕”的一个属性，并不是一个独立的领域概念；
4）删除“中国人”：“中国人”只是“收银员”的一个属性，并不是一个独立的领域概念；
5）删除“条形码”：“条形码”只是“商品”的一个属性，并不是一个独立的领域概念；
经过上面的提炼步骤后，就得到了真正的POS机领域类，详细如下：
顾客、收银员、商品、扫描仪、钱、信用卡、会员卡、小票、买单、键盘、屏幕
1.2. 加属性
找出领域模型的名词后，接下来一个重要工作就是将这些名词相关的属性找出来，使其更加准确。
但加属性和前面找名词有一点点差别：有的属性并没有在用例中明确给出，需要分析人员和设计人员额外添加，此时也是分析师的行业和领域经验起决定作用。
| 名词 | 属性 | 备注 |
|---|---|---|
| 顾客 | NA | 对于POS机来说，并不需要识别顾客的相关信息，因此在领域模型中，顾客是没有属性的 |
| 收银员 | 国籍、编号 | “国籍”由找名词步骤中的“中国人”提炼 |
| 商品 | 条形码、名称、价格 | 名称和价格并没有在用例中体现，但毫无疑问这是商品最基本的属性 |
| 扫描仪 | NA | 扫描仪是POS机的一个输入设备，POS机不需要识别扫描仪的相关信息，因此在领域模型中，扫描仪也是没有属性的 |
| 钱（现金） | 数量，币别 | 从领域分析的角度来讲，“现金”更专业一些 |
| 信用卡 | 卡号 | NA |
| 会员卡 | 会员号、积分、有效期 | NA |
| 小票 | 交易信息、POS机信息、收银员信息 | 小票的属性在用例中并没有详细体现，但有经验的分析师能够很容易识别出来 |
| 买单（交易） | 商品列表、日期时间、总额、支付信息 | 这里的属性看起来和“小票”一样，是因为“小票”本质上是给客户的一个交易记录。这里为了更加符合软件系统的属于习惯，可以将“买单“改为“交易”。 |
| 键盘 | NA | 和扫描仪类似，POS机不需要识别键盘信息 |
| 屏幕 | NA | 和扫描仪类似，POS机不需要识别屏幕信息 |
1.3. 连关系
有了类，也有了属性，接下来自然就是找出它们的关系了。
有了前面的工作，看起来连关系自然也是睡到渠成的事情，但不要忘了我们的这个例子是非常简单的，在一些复杂的系统中，领域模型之间的关系并不那么明显，菜鸟可能就只能看到最显而易见的一些联系，而系统分析师和设计师可以凭着丰富的经验、良好的技巧识别出来，这也是系统分析师和设计师的价值所在。
POS机的领域类关系如下（仅供参考，并不要求每个分析师和设计师都一定是这么理解，但总体来说应该相似）：
看起来有点不可思议，需求阶段白纸黑字的用例文档，经过我们一步一步的操作，最后得到了图形化的领域模型。
只要曾经画过甚至只是看过UML类图的同学都应该很容易发现，领域模型和设计类图非常相似，面向对象终于有了雏形了