2.1　理解业务

理解业务阶段在软件工程中叫作业务分析。关于整个业务分析的过程，有些书已经讲得比较透彻，下面仅讲解要点，并列举一些原创的、前后贯通的例子。

在没有任何标准和规范之前，对业务进行描述只能通过文字。有了UML之后，可以用UML中的一些形式把对业务的理解描述出来，形成业务模型，以便读者更容易理解。在项目中，最先理解业务的往往是产品人员或业务人员，但他们往往没有掌握UML和建模工具，所以要拿出规范的产物一般需要架构师的支撑。

对业务的理解不能只停留在脑子里，需要由书面的形式表达出来。可以通过一静一动两种角度来描述业务，“静”指的是领域模型，“动”指的是业务流程。

2.1.1　领域模型

市面上有专门介绍领域驱动的书籍，但没有专门介绍领域模型的书籍。这是因为领域模型的内容总体不多，难以独立成书，所以通常以章或节的形式存在。在实际工作中，领域模型最大的问题是，大家不清楚它应该在什么时候分析，分析到什么程度，其作用又是什么。

架构师的工作始于对业务的理解。要想理解业务，首先要整理领域模型。领域模型的定义有些晦涩难懂，本书给出的定义如下：将业务中的概念梳理出来绘制成一张类图就是领域模型。业务中的概念包括人、物、事和规则。绘制领域模型的思路如下：首先识别业务中的事（这是业务的核心），然后围绕这些事补充相关的人、物和规则。领域模型是类图，属于UML中的结构图，以静态的方式表达业务中的核心内容，是理解业务的基础，也是系统要解决的最基本的问题。

待开发系统与领域模型有什么关系呢？需要注意的是，业务的运转不完全是信息系统在发挥作用，其中可能有一部分仍然由人工操作，新系统引入后可能只能解决领域模型中的部分问题。

领域模型的表现形式是UML类图，根据内容的充实程度可以分为多个层次，即只有类、类中有关键属性、类中包含所有属性、类中不仅有属性还有方法。

根据内容的丰富程度可以将领域模型的作用分为以下几个层级。

·能够帮助团队成员对业务的基本概念形成一致的理解。

·指导功能设计，围绕领域模型中的类和关系线可以推导出大部分系统功能。

·指导数据库设计，基于领域模型可以形成数据模型设计。

·指导开发，在领域模型中，如果属性和方法完备，并且分析得较为严谨，就可以将这个类设计转换成代码中的领域层，并用于开发。领域层向上支撑业务逻辑层，可以让业务逻辑层不必直接访问数据访问层。

领域模型做到什么程度为好呢？在最开始的业务理解阶段，可以不必投入过多精力来分析细节，建议只分析到类级别，最多加上关键属性即可。

图2-1所示为在业务理解阶段分析出来的领域模型示例，下面介绍绘制该图的思路和过程，以及最后要达到何种程度为好。

领域模型的表现形式是UML类图（关于类图的绘制方法请参考相关书籍，本书不再探讨，只探讨要绘制什么类、梳理什么样的关系）。下面以一个常见的会议问题为例展开介绍，避免读者花费额外的精力理解特定业务相关的东西。领域模型中的元素基本上可以归纳为人、物和事。可以从事出发，首先识别业务中核心的事。这里的事比较明显，就是举行会议，所以可以先在正中间绘制会议类。办成一件事需要有人和物的参与，所以将所有参加会议的人定义为参会者，这些参会者可以细分为主持人、记录员和一般参会者。最重要的物是会议室，没有会议室就无法开会，而会议室中还需要一些设备，关键设备是投影仪或大屏幕电视。为了举行一场会议，需要提前预约会议室，预约会议室的行为可以作为事，相关的人是预约者。预约成功后需要向所有参会者发送通知邮件，这件事也比较重要，所以需要体现。然后考虑会议中需要干什么，会议可以抽象为各个参会者轮流发言的过程，所以发言可以作为一件事提取出来，每个参会者在发言过程中可能会演示一些内容，这些内容与发言存在关联关系。整个会议过程中可能会有人记录，在会议结束后形成一份会议记录，基于会议记录向所有参会者发送会议结果。所以，会议记录作为重要的物被提取出来，会议结果通知作为重要的事被提取出来。至此，所有的核心类已经出来了，但是需要补充一些重要的属性，如对于会议来说，最基本的是名称和内容；对于会议室来说，最基本的是地点和参会人数；对于会议中的每轮发言来说，最重要的是谁在什么时间讲了什么，对应的属性是发言人、发言内容、发言开始时间和发言结束时间。其他次要属性，以及肯定可以分析清楚的属性，可以暂不考虑。重要的关系是数量上的对应关系及泛化关系。大部分是一对一的关系（可以省略），着重体现一对多或多对多的关系。可以对会议-参会者、会议-发言、会议室-会议设备标注一对多的关系，一般参会者、主持人、记录员与参会者是泛化关系，投影仪和大屏幕电视与会议设备是泛化关系。通过以上步骤就可以得到图2-1。为了说明各个类代表人、物或事，可以用板型《人》、《物》和《事》对各个类进行标注，实际分析时可以不标注。此时就是业务分析初期阶段比较理想的程度，已经确定了整个业务中核心的内容和关系。

下面介绍领域模型和待开发系统的关系。领域模型能够说明的是业务本身，业务是否能够开展通常和有没有系统并无关系。在没有会议管理系统时，会议一样在开展，只不过其中一些事发生了就发生了，不会被记录，或者由人工记录；一些事是人工办理的；一些记录信息的物是纸质的。有了系统以后，一些事会被自动记录；一些事是系统处理的，更加高效；一些纸质的信息变成电子数据。总而言之，人、物、事还是那些，只不过形式发生了变化，效率得以提升。系统将在背后支撑领域模型中一部分关系的运转。设想一下，如果开发一个系统能支撑会议领域模型中所有的类和关系，那么能否是一个很好的会议管理系统呢？

分析领域模型一般存在以下问题。

·没有搞清楚领域模型的作用。基于现实情况，要实现真正的领域驱动设计，直至开发是不太可操作的，因为没有那么多善于进行面向对象分析与设计的人员。领域模型的主要作用还是支撑对业务的理解，更进一步是作为数据模型设计的依据。

·将领域模型当成数据模型来绘制，比较典型的现象是对类的命名使用了“数据”、“信息”和“记录”等，这明显是将领域模型当成数据模型来思考的。

·过于关注细节，缺乏宏观思考。很多人绘制的领域模型中，属性是密密麻麻的一大堆，而宏观上的类却很少。

·关系梳理不当。类之间的关系不正确，未体现数量上的对应关系，本应是属性的却搞成了类。

2.1.2　业务对象

领域模型是一种静态内容和关系的表示，要想搞清楚业务是如何运转的，还要有动态的业务流程的描述。按照面向对象的思想，可以认为业务流程是由多个业务对象通过相互协作来完成的。因此，分析业务流程的基础是识别业务对象。具有行为能力的业务对象有人和系统，其中人有两种——组织外的是业务执行者，组织内的是业务工人，参与的系统是业务实体。

需要说明的是，业务的主体是一个组织，组织拥有多项业务，每项业务可能由多个系统来支撑。拥有业务的组织通常是软件企业的客户。

识别出所有的业务对象，按照所属组织及对象分类，可以整理出一张业务对象图，如图2-2所示。这并非某种标准的UML图，仅仅是利用了一些UML元素。业务对象图的关键在于将各种业务对象区分清楚，以及归属的组织识别正确。有时一项业务是由多个组织的多个系统和人员协作完成的，如外卖订餐。

2.1.3　业务用例

有了业务对象作为抓手，就可以进一步分析业务用例了。所谓业务用例，是指一个组织向外部人员提供的某种业务服务。梳理业务用例可以采用业务用例图。业务用例图是一种标准的业务模型图，表现形式为UML用例图，其中的元素与常规用例有所区别，如人和用例都带有斜线。图2-3所示为一家餐厅的业务用例示例。

分析业务用例，要在宏观上进行高度的概括和总结。例如，一家餐厅就是解决人们的吃饭问题的，所以其业务用例就是面向顾客提供堂食和外卖。有的人分析业务用例会分析出很多，但业务用例不是操作层面的，而是高度抽象和概括的一个组织要办的大事，这种大事往往是支撑该组织的核心收入的，在数量上一般不多。

2.1.4　业务流程

识别出业务用例的下一项任务就是分析业务流程。理解业务最终就是要搞清楚各个业务用例的流程是什么样的。表述业务流程可以用UML顺序图，描述一个业务用例是如何通过多个业务对象来协作完成的。

需要注意的是，业务流程分为现状和将来。在刚开始分析的时候要描述现状。等系统构建完毕，则将整个系统新的业务对象插入现有流程中，使业务能够运转得更好。业务流程现状示例如图2-4所示。可以看出，当前这家餐厅没有任何信息系统，全部由人工操作。

业务流程设计示例如图2-5所示。相对于图2-4来说，其中引入了新系统，所以很多操作是通过新系统来完成的，这对于大餐厅来说是必要的，可以大大提高效率、降低人力资源消耗。

通过分析业务流程，架构师可以认识待建系统在客户的整个业务流程中的作用，对于系统价值的把握十分关键。经常说架构师要理解业务，但对业务的理解不能只停留在脑海中，如果不能以书面形式整理出来，获得相关方面的认可，就不能说完成了业务理解。

至此，本节通过领域模型梳理清楚了业务中的人、物、事，又通过业务流程梳理清楚了业务开展过程，并设想了引入待建系统后新的方式，讲清楚了系统的价值，这时就达到了可以立项的条件。架构师对业务的理解达到以上程度就可以了。架构师不需要关注业务细节，那些是业务人员要搞清楚的问题。