一、什么是业务领域建模
领域建模：
从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。
顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。
理论派观点：
Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；所有同行企业，其业务模型必定有非常大的共性和内在的规律性。
由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。
领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。
实战派观点：
领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。
是需求分析人员与用户交流的有力工具，是彼此交流的语言。
领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。
业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。
软件开发过程：业务建模、需求、分析、设计。
在软件开发过程中我们接触到的领域模型属于实战派。
从这个定义我们可以看出,领域模型有两个主要的作用:
发掘重要的业务领域概念
建立业务领域概念之间的关系
二、如何领域建模
领域模型如此重要,事实上领域建模非常简单,概括一下就是“找名词”!
一个关键的问题还没有说明:从哪里找? 如果你还记得领域模型是“需求到面向对象的桥梁”,那么你肯定一下子就能想到:从需求模型中找,具 体来说就是从用例中找。
归纳一下域建模的方法就是“从用例中找名词”。 当然,找到名词后,为了能够更加符合面向对象的要求和特点,我们还需要对这些名词进一步完善,这就 是接下来的步骤:加属性,连关系!
最后我们总结出领域建模的三字经方法:找名词、加属性、连关系。
A. 发现类和对象：尽可能多的找出概念类（识别方法：概念类分类列表、名词性短语）
a.概念分类列表：人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构（对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等）
b.名词分析法：识别问题域和用例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是一种标识、状态和行为）
B. 建立类之间的关联（关联、继承、依赖）
关联：类之间的某种语义关系包括聚合，组合
继承：一般到特殊
依赖：表明一个元素（源元素）的定义或实现依赖另一个元素（被依赖元素）的定义或实现
C. 添加类的重要属性（类的语义完整性、类的作用、问题域相关特性等）
a.语法：可见性 属性名：类型 多重性=默认值{特性表}
/ [可见性] 属性名 [：类型] [=初始值]
b.属性类型是简单的数据类型为佳，如果是复杂概念，考虑是否单独作为一个概念类
c.任何属性都不表示外键，即不应该用属性来联系概念类，区别于数据库设计中的外键
三、我的工程实践的业务领域建模
我的工程实践是银行贷款系统，业务领域建模具体如下：
1、引言
一套完善的银行贷款系统，不仅可以大大提高贷款业务的办理效率，而且可以根据客户的需求快速完成新业务的开发和重组，改善银行的服务品质。然而对于像银行贷款系统这种大中型系统的开发，很难直接对其进行分析设计，需要借助建立业务模型来分析系统。
UML（Unified Modeling Language，统一建模语言）不仅提供了描述软件系统模型的概念和图形表示法，而且能准确地表达面向对象的概念，体现面向对象的分析和设计风格。
RUP（Rational Unified Process，统一建模过程）是 Rational 公司为用户提供的基于 UML 的软件开发过程，它是一种基于用例驱动的，以系统架构为中心的迭代与增量开发软件的过程。
下面是从银行贷款的实际业务出发，在遵循 RUP 迭代开发思想的指导下，利用 UML 开发工具（如 Rational Rose）建立了银行贷款系统的 UML 用例模型。在用例模型的基础上，详细介绍了从用例描述中提取和筛选系统类的语法分析过程，通过分析类之间的关系，建立了银行贷款系统的类图模型，实现了从业务需求分析到系统设计和编码的无缝连接。
2、业务建模
业务建模在软件开发过程中起了非常重要的作用，通过业务建模可以帮助开发人员了解现状，启发愿景和需求，为后续的分析和设计提供精确有效的参考。实施业务建模可以按下文提及的步骤进行。
（1）选定业务领域
对业务领域的划分应该有一个明确的界限，这一步是基本前提，如果范围不明确，会导致以后的分析缺乏依据，或者产生矛盾。本文引用的实例是银行贷款系统，通过对银行贷款业务的需求调研，选定银行贷款系统的业务领域如图 1 所示。
图 1 银行贷款系统的业务领域
（2）识别业务执行者
业务执行者（business actor）是在系统之外与业务交互的人或组织；业务工人（business worker）是在系统内帮助完成业务处理的服务人员或系统。一般来说，真正的顾客才是业务系统的执行者，如银行贷款系统的业务执行者为来银行办理贷款业务的客户。
（3）识别业务用例
业务用例是业务单元为业务执行者提供的完整价值，需要从业务执行者的角度对每一个业务单元进行分析提取业务用例。UML 用例图主要由业务用例和业务执行者构成，通过“业务执行者——业务用例”的模式来反映业务执行者驱动业务用例的状况。基于以上对业务执行者和业务用例的识别和分析，建立的贷款业务处理单元的用例图，如图 2 所示。
图 2 贷款业务处理单元用例模型
（4）描述业务用例
对业务用例的描述是为了说明各业务用例的实现过程。业务用例的描述有两种方式：用例文档和 UML 动态图：如序列图或活动图。如图 3 所示为申请贷款发放的活动图。
采用用例文档来描述业务用例需要遵循一个用例模板，该模板中一般应包括以下信息：用例名称、用例编号、用例的简短描述、用例的业务执行者、业务工人、前置条件、后置条件、用例的输入、输出、用例的执行过程等。
图 3 申请贷款发放活动图
3、建立类图模型
（1）候选类
本文采用简单的语法分析方法提取类：依据用例描述文档找出其中所有的名词，将名词作为类和对象的候选者。从申请贷款发放的用例描述文档中找出的名词有：客户、贷款业务办理申请书、信贷文件建立人员、客户号、客户信息、客户姓名、地址、证件类型、贷款编号、担保品编号、担保品价值、授信客度、合同编号、合同信息、存款账户、贷款账户、借款凭证等。
（2）类的筛选
接下来严格考察每个候选类，从中去掉不必要的，仅仅保留确实应该记录其信息或需要其提供服务的类。筛选类的分析方法和依据有：
·要寻找隐含在字里行间的名词，合并含义或性质相同的名词，例如把客户和客户信息合并为客户；
·有些名词仅作为类的属性，将其去掉。如果一个名词有另外的名词作为附属，或有一个动词受此名词的支配，那么通常该名词就是类。候选类中有很大一部分都是类的属性，如姓名、贷款编号、担保品价值等，将这些词从候选类中删除；
·一般来讲，参与业务活动的人、组织机构、系统管理的设备、需要长期保存的事件、业务运转的表单、票据等都是类；另外还有一些为了业务运转而附加的类，如贷款业务办理申请书、收费凭证、借款凭证等。
通过以上方法对候选类进行分析，经过筛选最后剩下以下 8 个实体类：客户、账户、贷款产品、合同、业务凭证、信贷文件、担保品、贷款办理人员。
在类的提取过程中，可能会因为分析不全面导致漏过某个真正的类或者把一个不该作为类的词加进来了，这并不重要，根据 RUP 的迭代特性会使开发人员在每一个阶段都进行以上分析，用尽量小的代价来修正所暴露出的错误，最终使筛选出的类能够合理和完整。
（3）定义类的属性和行为
属性是类的一个描述特征，类的行为描述了这个类在系统中所提供的服务。和类的来源一样，类的属性和行为也有一部分来源于用例描述文档。文档中的形容词作为确定类的属性的线索，动词作为类行为（操作）的候选者。
（4）建立类之间的关系
找出实体类，确定了类的属性和行为以后，还需要分析任意两个类之间的关系。类之间的关系主要有四种：泛化、关联、聚合、依赖。在 UML 类图中这四种关系分别用不同的线区分出来。关联关系，用来表明两个类之间的点对点关系，每个类都会调用另一个类提供的操作，如贷款办理人员可以调用账户类中开立账户这一操作，来为客户开立账户。聚合关系，或者说是一种拥有的关系，是较强的关联关系，如客户拥有账户。泛化关系，表示类与类之间的继承关系，或类对接口的实现关系，如个贷产品、企贷产品与贷款产品之间就是一种继承关系。依赖关系，类 A 要完成某个功能必须引用类 B，则 A 与 B 存在依赖关系，依赖关系是弱的关联关系，如贷款账户的开立需要先借助于建立信贷文件。通过分析申请贷款发放中实体类之间的关系，建立申请贷款发放的 UML 部分类图模型，如图 4 所示。
图 4 申请贷款发放的类图
4、设计和测试
建立类图后，开发人员可以利用 UML 工具（如 Rational rose）自动生成程序代码框架，并对代码框架进行修改和补充，形成完整代码。进一步可根据代码逆向生成 UML 模型，通过这种双向工程可较好地保证模型与代码的一致性。测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，才能保证开发的质量，降低开发的风险。