## 连载：面向对象葵花宝典：思想、技巧与实践（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类图的同学都应该很容易发现，领域模型和设计类图非常相似，面向对象终于有了雏形了