（23） – 领域建模三字经
最后更新于：2022-04-01 07:29:33
## 连载：面向对象葵花宝典：思想、技巧与实践（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类图的同学都应该很容易发现，领域模型和设计类图非常相似，面向对象终于有了雏形了