5. 领域模型

领域模型是面向对象分析和设计的第一步！！

完成了需求分析以后，咱们已经有了一个良好的开端，但咱们的主角“面向对象”还不见踪迹。前面咱们提到，需求分析和面向对象是没有直接关系的，需求分析阶段是不区分是面向对象仍是面向过程，那么何时才真正开始面向对象的工做呢？

答案就在本章：领域建模。

从领域模型开始，咱们就开始了面向对象的分析和设计过程，能够说，领域模型是完成从需求分析到面向对象设计的一座桥梁。

领域模型，顾名思义，就是需求所涉及的领域的一个建模，更通俗的讲法是业务模型。

参考百度百科（http://baike.baidu.cn/view/757895.htm ），领域模型定义以下：

领域模型是对领域内的概念类或现实世界中对象的可视化表示，又称概念模型、领域对象模型、分析对象模型。它专一于分析问题领域自己，发掘重要的业务领域概念，并创建业务领域概念之间的关系。

从这个定义咱们能够看出，领域模型有两个主要的做用：

• 发掘重要的业务领域概念
• 创建业务领域概念之间的关系

5.1 领域模型三字经

    领域模型如此重要，不少同窗可能会认为领域建模很复杂，须要很高的技巧。然而事实上领域建模很是简单，简单得有点难以让人相信，领域建模的方法归纳一下就是“找名词”！

    许多同窗看到这个方法后估计都会笑出来：太假了吧，这么简单，找个初中生都会啊，那咱们公司那些分析师和设计师还有什么用哦？

    分析师和设计师固然有用，后面咱们会看到，即便是简单的找名词这样的操做，也涉及到分析和提炼，而不是简单的摘取出来就可，这种状况下分析师和设计师的经验和技能就可以派上用场了。但领域模型分析也确实相对简单，即便没有丰富的经验和高超的技巧，至少也能完成一个能用的领域模型。

    虽然咱们说“找名词”很简单，但一个关键的问题尚未说明：从哪里找？

    若是你还记得领域模型是“需求到面向对象的桥梁”，那么你确定一会儿就能想到：从需求模型中找，具体来讲就是从用例中找。

    概括一下域建模的方法就是“从用例中找名词”。

    固然，找到名词后，为了可以更加符合面向对象的要求和特色，咱们还须要对这些名词进一步完善，这就是接下来的步骤：加属性，连关系！

    最后咱们总结出领域建模的三字经方法：找名词、加属性、连关系。

    接下来咱们经过一个样例来看看具体如何创建领域模型。

5.2 找名词

咱们经过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机领域类，详细以下：

顾客、收银员、商品、扫描仪、钱、信用卡、会员卡、小票、买单、键盘、屏幕

5.3 加属性

找出领域模型的名词后，接下来一个重要工做就是将这些名词相关的属性找出来，使其更加准确。

但加属性和前面找名词有一点点差异：有的属性并无在用例中明确给出，须要分析人员和设计人员额外添加，此时也是分析师的行业和领域经验起决定做用。

名词	属性	备注
顾客	NA	对于POS机来讲，并不须要识别顾客的相关信息，所以在领域模型中，顾客是没有属性的
收银员	国籍、编号	“国籍”由找名词步骤中的“中国人”提炼
商品	条形码、名称、价格	名称和价格并无在用例中体现，但毫无疑问这是商品最基本的属性
扫描仪	NA	扫描仪是POS机的一个输入设备，POS机不须要识别扫描仪的相关信息，所以在领域模型中，扫描仪也是没有属性的
钱（现金）	数量，币别	从领域分析的角度来说，“现金”更专业一些
信用卡	卡号	NA
会员卡	会员号、积分、有效期	NA
小票	交易信息、POS机信息、收银员信息	小票的属性在用例中并无详细体现，但有经验的分析师可以很容易识别出来
买单（交易）	商品列表、日期时间、总额、支付信息	这里的属性看起来和“小票”同样，是由于“小票”本质上是给客户的一个交易记录。 这里为了更加符合软件系统的属于习惯，能够将“买单“改成“交易”。
键盘	NA	和扫描仪相似，POS机不须要识别键盘信息
屏幕	NA	和扫描仪相似，POS机不须要识别屏幕信息

5.4 连关系

有了类，也有了属性，接下来天然就是找出它们的关系了。

有了前面的工做，看起来连关系天然也是睡到渠成的事情，但不要忘了咱们的这个例子是很是简单的，在一些复杂的系统中，领域模型之间的关系并不那么明显，菜鸟可能就只能看到最显而易见的一些联系，而系统分析师和设计师能够凭着丰富的经验、良好的技巧识别出来，这也是系统分析师和设计师的价值所在。

POS机的领域类关系以下（仅供参考，并不要求每一个分析师和设计师都必定是这么理解，但整体来讲应该类似）：

  

看起来有点难以想象，需求阶段白纸黑字的用例文档，通过咱们一步一步的操做，最后获得了图形化的领域模型。曾经画过甚至只是看过UML类图的同窗都应该很容易发现，领域模型和设计类图很是类似，面向对象终于有了雏形了

5.5 FAQ

    1. 为何在POS机的领域模型的类中没有看到类的方法呢？

        答：领域模型中的类不是软件类，而只是用于描述领域的实体，不须要关注方法。

    2. 若是没有用例，是否就无法获得领域模型？

        答：不必定，对于那些经验丰富的分析师来讲，没有用例一样可以分析出领域模型。

    3. 若是是面向过程，须要进行领域模型分析吗？

        答：基本不须要，面向过程的分析只须要分析数据结构和算法。

    4. 在用例模型中提到键盘和屏幕须要使用中文，这种信息在领域建模后就丢失了吗？    

        答：确实是这样，领域建模没法关注用例的约束和限制，例如：性能、可靠性等。但咱们不用担忧这些

               需求不能知足，由于后面设计的时候还会回过头来核对用例。

5.6 小结

• 领域模型是“需求到面向对象的桥梁”。
• 领域建模的三字经方法：找名称、加属性、连关系。
• 从用例中能够找到领域模型的名称。
• 不是全部的属性都在用例中存在。
• 领域模型中的类不是软件类，而只是用于描述领域的实体，不须要关注方法。