5. 领域模型

2019独角兽企业重金招聘Python工程师标准>>>

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

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

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

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

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

参考百度百科（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 小结

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

转载于:https://my.oschina.net/jimilee/blog/750527