看起来有点不可思议，需求阶段“白纸黑字”的用例文档，经过我们一步一步的操作，逐步就得到了“图形化”的领域模型，面向对象初具雏形。
领域建模的三字经方法：找名词、加属性、连关系。
我们接下来以一个样例看看领域模型具体如何建模。
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类图的同学都应该很容易发现，领域模型和设计类图非常相似，面向对象终于有了雏形了
================================================
转载请注明出处：http://blog.csdn.net/yunhua_lee/article/details/22794315
================================================