CN116703258B - 一种分析建模方法 - Google Patents

Abstract

一种分析建模方法，包括工艺方法论和工艺工具平台，工具承接工艺方法论，将工艺方法论的思想使用工具进行体现，工艺方法论重顶层设计，重工艺过程，轻开发编码，根据业务需求和边界划分原则，推导出最符合业务需求的操作过程；工具对上述工艺方法论推导的操作过程提供数字化管理能力，提供模型资产的管理能力，管理工艺中各工序的成果产物。形成具有良好可视化，具备可操作性的工具，辅助客户在该工具的操作指引下，基于业务建模的成果，迅速地进行应用的分析建模。

Description

一种分析建模方法

技术领域

本发明主要应用于金融科技领域的应用分析阶段，以便将业务需求进一步转化为金融科技应用开发可理解和识别的业技融合语言，借鉴领域驱动设计（Domain DrivenDesign）思想以及UML绘图方法来确定应用边界，以匹配业务需求中所隐含的业务边界，将需求侧使用自然语言编写的业务流程，从面向过程转变为面向对象的，以匹配金融科技领域逐步转变为使用面向对象的语言编程的发展趋势，降低后续金融科技领域软件设计阶段的复杂度。

背景技术

金融科技领域软件系统的复杂度主要体现在业务的复杂性和变化性，以及技术的复杂性和响应速度，金融科技领域的业务模块多，业务流程复杂，业务系统之间的高度关联性也加剧了复杂度，同时业务的发展、演变较快，业务边界的重组（拆分、合并）比较频繁。因此与之相对应的应用系统边界，也要快速响应和匹配业务边界的重组。

除此之外，随着硬件设备和软件技术的发展，软件架构也发生了很大的变化，从单体架构到集中式架构，再到当今和未来一段时期优势将更加突出的分布式微服务架构。微服务解决了集中式架构的软件不能快速响应需求的变化等等单体应用的很多问题，但是又导致了过去一段时期经常出现的新问题，例如：微服务的拆分不考虑业务需求的边界、微服务单纯从技术视角考虑而过度拆分或不合理拆分等等。

传统软件工程的应用系统边界若遇到业务边界的重组，存在着承接和映射关系不清晰、重构或改造困难、响应速度慢等问题。应用系统的边界和微服务的拆分不考虑业务需求的边界、微服务单纯从技术视角考虑而过度拆分或不合理拆分等问题。业务逻辑的复杂度与技术实现的复杂度混淆在一起，难以划分业务逻辑与技术实现的边界。业务人员与技术人员，语言不统一，导致需求的理解存在一定的偏差。

发明内容

本发明的目的主要解决以上背景技术的问题。

针对背景技术所存在的问题，我们采用“工艺方法论+工艺工具平台”的方式来解决以上问题，RADC工艺方法论借鉴了领域驱动设计的思想，并对部分概念重定义。工具承接RADC工艺方法论，进一步将其思想使用工具进行体现，命名为RADC工艺-分析建模。

RADC工艺及工具可以解决以下问题：

1）RADC工艺方法论重顶层设计，重工艺过程，轻开发编码，根据业务需求和边界划分原则，自然推导出最符合业务需求的结果。

2）借鉴领域驱动设计DDD的思想，通过领域、聚合等边界来分离业务复杂度和技术复杂度，来降低软件系统设计的复杂度；例如：子域将领域进一步分解、限界上下文将子域进一步分解、聚合将限界上下文进一步分解细化。本发明中去掉了限界上下文和子域，保留了领域、聚合，并使用“应用组件”来替代限界上下文和子域，使用领域模型中的业务需求等相关知识进行抽象而形成应用组件。

3）RADC工艺将业务需求中使用自然语言编写的业务流程，从面向过程转变为面向对象，据此识别领域对象、划分边界、分析用例和识别功能。

4）工具承载了上述应用边界划分考虑业务边界的承接关系、面向对象的特点，以及重顶层设计、轻开发编码的思想。

5）工具对上述RADC工艺方法论的操作过程提供数字化管理能力，提供模型资产的管理能力，管理工艺中各工序的成果产物。解决了大量使用表格、绘图、文字的线下管理方式带来的更新困难、关联关系复杂等问题。

6）工具设计了动名词库，用于解决业务人员与技术人员语言不统一的问题，真正实现了业技融合的理念。

本发明借鉴领域驱动设计DDD的思想，通过领域驱动设计过程，引用架构分层策略，领域驱动的四重边界分析等技术，在此基础上做进一步的重定义。下面依次来介绍各技术点。

战略设计：

领域驱动设计在战略设计层面，从业务视角出发使技术人员专注于问题域，从领域专家那里获得领域见解，通过模块划分建立领域服务边界，通过限界上下文明确服务的职责。

战术设计：

领域驱动设计在战术设计层面，从技术的视角出发，根据通用语言对单个限界上下文进行领域建模，提炼有效的业务模型，实施领域建模、架构设计完成软件的落地。

本发明中采用战略设计和战术设计来完成领域驱动设计，如图1所示，战略设计明确做什么的问题，战术设计明确怎么做，分别从业务的视角专注于问题域，通过应用组件来划分领域服务，通过聚合来明确领域服务边界，从技术视角，实体和值对象用于对具有不同领域特征的领域对象进行建模；聚合将一组领域对象绑定为一个整体，以控制事务；服务则充当领域模型的接口，具有无状态的特点；而资源库则用于封装领域对象的数据库访问操作。

如图2所示，领域驱动设计中利用四重边界进行架构设计：

分而治之 ：DDD通过规划四重边界，把领域知识做了合理的固化和分层。领域中有核心子域和支撑子域、通用子域，子域中又拆分成多个限界上下文（BC），一个限界上下文中又根据领域知识核心与否进行分层，领域层中按照多个业务（子域）的强相关性形成一个聚合。

【第一重边界】确定愿景与目标，确定问题空间，确定核心子领域、通用子领域（多个子领域可以复用）、支撑子领域（额外功能）；

【第二重边界】解决子域里的限界上下文，就是一道进程隔离层面的物理边界；

【第三重边界】每个限界上下文内，使用分层架构划分为：接口层、领域层、应用层、基础设施层，形成限界上下文的最小隔离；

【第四重边界】领域层里为了保证各个领域的完整性和一致性，引入聚合的设计作为隔离领域模型的最小单元。

本发明中根据领域驱动设计的四重边界设计架构的方式，进一步做了改造，去除了子域和限界上下文的边界，整合为应用组件，如图3所示。两种方式定义应用组件，一种是业务建模需求，承接一个或者多个业务组件，预设为应用组件，另一种是非业务建模需求，基于现状系统的模块划分、行业经验以及业务发展趋势预设应用组件，后续迭代优化。在应用组件内，使用分层架构划分为交易层，领域层，应用层、基础设施层，领域层，保证业务的完整性和一致性，将领域对象聚合在一起，形成聚合，作为隔离领域模型的最小单元。

图4示出了领域驱动设计中的分层架构，包括：

用户接口层：负责向用户展现信息以及解释用户命令。

应用层：应用层是领域层的上层，依赖领域层，是各聚合的协调和编排，原则上是不包括任何业务逻辑，不保留业务对象的状态，但它保有应用任务的进度状态。它以较粗粒度的封闭为前端接口提供支持。

领域层：领域层聚焦业务对象的业务逻辑实现，体现现实世界业务的逻辑变化。它用来表达业务概念、业务状态和业务规则。

基础设施层：作为其它层的支撑库存在，提供层间的通信，实现对业务对象的持久化，为其他任意层提供服务，为了解决耦合的问题，采用依赖倒置原则。

本发明对领域驱动设计中的分层架构进行了改进提出了一种服务分层架构，如图5所示，包括：

交易层（TXS）：将领域驱动设计分层架构中的“用户接口层”重新定义为“交易层”，主要负责，交易服务/接口的定义，以及服务编排。对外提供服务。

应用层（APS）：依赖领域层，协调和编排各聚合，不包含业务规则，不保留业务对象的状态，但保有应用任务的进度状态。以领域服务的粒度提供支持

领域层（DMS）：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则。

基础设施层（INFRA）：提供仓储服务实现，数据实体的持久化。

工艺工具平台承接工艺方法论（分析建模方法），形成以下功能，旨在完成通过分析建模功能，能够承接业务建模的成果实现应用分析建模，为后续的应用设计提供支持。

1）定义应用组件；

2）完善业务规则；

3）分析领域对象；

4）聚合分析；

5）用例分析；

6）应用分析成果。

具体而言：本发明提供了以下技术方案：

一种分析建模方法，包括工艺方法论和工艺工具平台，原理是工具承接工艺方法论，将工艺方法论的思想使用工具进行体现，其特征在于：

工艺方法论是根据业务需求和边界划分原则，推导出最符合业务需求的操作过程；

工具用于对上述工艺方法论的操作过程提供数字化管理能力，提供模型资产的管理能力，管理工艺中各工序的成果产物。工具设计有动名词库。所述的工艺方法论，包括三重边界，其特征在于：

第一重边界是应用组件；

第二重边界是针对应用组件来确定层级，使用分层架构划分为交易层，领域层，应用层、基础设施层；

第三重边界是针对领域层，做聚合设计。第二重边界中，每个层级的定义如下：

交易层：将领域驱动设计分层架构中的“用户接口层”重新定义为“交易层”，主要负责，交易服务/接口的定义，以及服务编排，对外提供服务。

应用层：依赖领域层，协调和编排各聚合，不包含业务规则，不保留业务对象的状态，但保有应用任务的进度状态。以领域服务的粒度提供支持

领域层：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则。

基础设施层：提供仓储服务实现，数据实体的持久化。

其中，第三重边界中，将领域对象聚合在一起，形成聚合，作为隔离领域模型的最小单元。

本发明还提供了一种工艺工具平台，其用于承接上述工艺方法论，旨在完成通过分析建模功能，能够承接业务建模的成果实现应用分析建模，为后续的应用设计提供支持。

其中分析建模包括以下工序：

1）定义应用组件；

2）完善业务规则；

3）分析领域对象；

4）聚合分析；

5）用例分析；

6）应用分析成果。

其中：步骤1）定义应用组件包括：步骤1.1）定义应用组件，步骤1.2）绘制应用组件全景图。

其中：步骤3）分析领域对象包括：3.1）识别领域对象，3.2）绘制领域对象关系图，3.3）绘制领域对象时序图。

其中：步骤5）用例分析包括：5.1）定义功能项，5.2）识别功能，5.3）绘制用例工作流图。

综上，本发明显著的进步性具体如下几点：

（1）工艺方法论重顶层设计，重工艺过程，轻开发编码，工艺方法论通过领域、聚合等边界来分离业务复杂度和技术复杂度，来降低软件系统设计的复杂度；其中，工艺方法论将业务需求中使用自然语言编写的业务流程，从面向过程转变为面向对象；使用领域模型中的业务需求等相关知识进行抽象而形成应用组件；

（2）工具承载了上述应用边界划分考虑业务边界的承接关系、面向对象的特点，以及重顶层设计、轻开发编码的思想，用于解决业务人员与技术人员语言不统一的问题，真正实现了业技融合的理念；

（3）借鉴领域驱动设计降低了软件系统设计的复杂度，同时承接了领域驱动设计的方法，形成具有良好可视化，具备可操作性的工具，辅助客户在该工具的指引操作下，基于业务建模的成果，迅速地进行应用的分析建模。对比传统的应用分析方法，“工艺方法论+工艺工具平台”的方式能够更好去做应用的分析建模。

附图说明

结合附图，并通过参考下面的详细描述，将会更容易地对本发明有更完整的理解并且更容易地理解其伴随的优点和特征，其中：

图1为本发明中领域驱动设计过程的示意图。

图2为本发明中领域驱动设计的四重边界示意图。

图3为本发明中三重边界的示意图。

图4为本发明中领域驱动设计的分层架构示意图。

图5为本发明中服务分层架构的示意图。

图6为本发明的分析建模工序图。

图7为本发明中应用组件一级框架的示意图。

图8为本发明中应用组件二级框架的示意图

图9为本发明中定义应用组件的界面示意图。

图10为本发明的定义应用组件交付物示例的示意图。

图11为本发明中绘制应用组件全景图的界面示意图。

图12为本发明业务规则的描述逻辑分类的示意图。

图13为本发明中完善业务规则的界面示意图。

图14为本发明中完善业务规则交付物示例的示意图。

图15为本发明中识别领域对象的界面示意图。

图16为本发明中识别领域对象交付物示例的示意图。

图17为本发明领域对象之间关系的示例图。

图18为本发明中的绘制领域对象关系图的界面示意图。

图19为本发明中的绘制领域对象时序图的界面示意图。

图20为本发明中聚合分析的界面示意图。

图21为本发明中聚合分析交付物示例的示意图。

图22为本发明中定义功能项具体原则的示意图。

图23为本发明中定义功能项的操作注意事项示意图。

图24为本发明中定义功能项的界面示意图。

图25为本发明中定义功能项交付物示例的示意图。

图26为本发明中识别功能的界面示意图。

图27为本发明中识别功能交付物示例的示意图。

图28为本发明中绘制用例工作流图的界面示意图。

图29为本发明中绘制用例工作流图交付物示例的示意图。

图30为本发明中应用分析成果的界面示意图。

图31为本发明中应用分析成果交付物示例的示意图。

具体实施方式

下面结合附图对本发明的具体实施方式做进一步说明。

以下实施例仅为清楚说明本发明而举例，并非对本发明实施方式的限定。

在实际操作中，可在下述说明的基础上根据需求做出变化和变动，但由本发明精神所引出的显而易见的变化或变动仍处于本发明的保护范围之中。

本文中的缩略语和关键术语定义如下：

应用组件：由一组具有特定业务功能与功能用途，并存在业务内在联系和相关性的服务所组成的聚合，专注于具体的业务逻辑处理和业务数据处理，提供企业级可复用的能力。一个或多个应用组件承接一个业务组件，一个应用组件能被多个业务领域使用。

实体：是一类对象、拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的全生命周期。

值对象： 是通过属性值来识别的对象，它将多个相关属性组合为一个整体概念。用来描述领域的特定方面，并且是一个没有标识符的对象，可分为单一属性值对象、属性集值对象。

领域对象：DO，Domain Object，又叫实体类，是从业务概念中抽取或提炼出来的、有形或无形的业务实体，是实体、值对象，及其属性和行为的充血模型集合。领域对象通常是有唯一编号、有状态的，尤其强调只能为充血模型。

动作：内部或外部的用户发起的，需要系统提供相应的服务去执行，通常为动名词结构。

行为：是领域对象自身具备的，可以自我控制的最小粒度动作，是构成领域对象充血模型的必要条件。

聚合：由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

聚合根：如果把聚合比作组织，那聚合根就是这个组织的负责人，聚合根也称为根实体，它不仅是实体，还是聚合的管理者和对外接口人。

通用语言：是团队统一的语言，团队中任何一个角色在同一个边界的软件生命周期里都使用统一的语言进行交流，其包含术语和用例场景，并且能够直接反映在代码中。

时序图：根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象交互。

持久对象：PO，persistence object，由一组属性和属性的get和set方法组成，PO对应数据库中的记录，一条记录就是一个PO对象，PO的每个属性对应数据库表的某个字段。

实施例中，分析建模阶段的工序，包括建模方法、工具功能以及交付物示例，方法用于指导工具的设计思路，工具体现功能，交付物为各工序完成后的成果产物。分析建模需要承接业务建模（流程建模、产品建模）的成果产物。

分析建模阶段的重点，是将需求侧用自然语言描述的业务流程，从面向过程转变为面向对象，据此识别领域对象、划分边界、分析用例和识别功能。在实操中需要不断迭代，确保工序及其成果产物间的依赖关系正确更新。

分析建模的主要工序共计11道，概要如图6所示。其中完善业务规则、聚合分析、应用分析成果的环节相对独立，只有一道工序。图7-8示出了应用组件一级框架和二级框架。

分析建模阶段工序成果产物清单：

1、定义应用组件

工序1.1：定义应用组件

（1）工艺方法

领域专家基于行业经验、业务需求，提出应用组件预设建议。决策层进行决策，达成共识后宣贯并分配工作。

若需求为业务建模需求，可参考业务组件的划分，至少将一个业务组件预设为一个应用组件，后续迭代调整；

若需求非业务建模需求，可基于现状系统的模块划分和本项目的规划，以及行业经验、趋势判断进行预设，后续迭代。

根据应用组件的概念和特征判断是否适合定义：

用概念判断：应用组件由一组具有特定业务功能与功能用途，并存在业务内在联系和相关性的服务所组成的集合，专注于具体的业务逻辑处理和业务数据处理，提供企业级可复用的能力，一个或多个应用组件承接一个业务组件，一个应用组件能被多个业务领域使用。

用特征判断：应用组件一般有以下特征：

复用性：应用组件的能力，可被不同的业务领域以及业务组件使用、可被不同的业务流程编排。

单一性：应用组件的职责单一、内聚，可以用具备生命周期的名词、或名词短于进行抽象概括。

独立性：应用组件可封装、可单独运行、部署和出售，应用组件间的功能互斥、不重叠。

可拆解：应用组件粒度不宜细到无法拆解，不宜用表达生命周期部分事件的动词、或动词+名词来命名。

用“业务组件”判断：业务组件必须全部被“应用组件”承接，避免遗漏而导致IT不能完全承接业务。

定义应用组件需明确的项至少包括：名称、目标（P）、定义（D）、范围（S），范围可用包括、不包括进一步强调。

根据应用组件划分原则，进一步明确应用组件承接分析的范围。各应用组件责任团队间需达成共识，避免遗漏、重叠。

（2）工具功能

基于行业经验、业务需求，进行应用组件划分建议 (对于业务建模需求，可参考业务组件的划分，将一个业务组件至少定义为一个应用组件)。决策层进行决策，达成共识后形成应用组件清单。图9示出了定义应用组件的界面。

（3）交付物示例

图10示出了工序1交付物示例的示意图。

工序1.2：绘制应用组件全景图

（1）工艺方法

参考业务领域、业务组件的图例、分层结构，根据应用组件清单，先进行分层框架设计、然后将相应的应用组件放在分层框架中，按应用组件的关联性，决定其摆放的远近位置。

优先参考业界领先的通用分层框架，定义应用组件的分层框架，一般为1~2级即可。

按照应用组件的范围、服务对象确定每个应用组件所处的层次结构。

相似性高、内聚性强的应用组件，紧邻摆放。

（2）工具功能

图11示出了工具功能的示意图。

（3）交付物示例

2.完善业务规则

工序2.1：完善业务规划

（1）工艺方法

完善业务规则是最细致的工序，虽然只有一道工序，但为便于理解，细分为以下主要几步：

整理业务规则；

适配产品条件；

引用业务对象/属性；

检查规则完整性。

1)整理业务规则：从业务角度表述业务规则；抽象归纳总结业务逻辑、去CPCP、能支持各种业务情况；复杂业务规则，需要建立复杂规则工作表格进行专项描述。针对每一个任务项下的工作事项，整理实现目的的方法——业务规则，

首先，业务规则是业务语言，对获取的各类信息务必进行加工转换，是所有业务人员能读懂的语言；

其次，业务规则应该是条理清晰、语义明确的；

需强调的是：业务规则是去差异的，是对不同处理场景的总结，能灵活支持各种需求；

最后，在落笔业务规则时，请参考后续的书写规范，力求用结构化的、自然语言清晰表达业务需求。

2)业务规则的描述逻辑：在业务规则中，应该使用自然语言来描述各种业务需求；业务规则表述了如何实现任务项下的工作事项，一定是用业务语言描述；更重要的是，业务规则是归纳总结后的标准处理，是能支持各种情况的，除规则适用范围的描述外，规则内容不应当直接引用“渠道、产品、客户”等。描述逻辑分为如图12所示的类别。

3)复杂规则描述：若业务规则中有复杂的、不适合用文字表述的，如表格、图示等，则可以建立复杂规则工作表进行专项描述。定义复杂规则应明确定义规则的名称、规则编号，并确保与业务中引用的规则名称与编号一致，如“根据XX、XX和XX，由复杂规则XXX（编号XXX）得到XXX”。手工描述时，引用复杂业务规则使用二维矩阵+复杂规则编号标识（xxx为复杂规则编号）。

4)适配产品条件：业务规则与产品建模相关，要使用产品建模成果。

根据业务规则识别对应的产品条件。

业务规则与产品条件勾稽，即可验证业务规则规则的齐全，也可检查产品条件提炼质量；

在业务规则中使用的产品条件用#xxx标识。

在"产品条件"列罗列该业务内用到的产品条件。

提出产品条件需求。

在识别过程中若发现有缺失的产品条件、或认为可以新增的产品条件，及时申请增加。

5)引用业务对象/属性：

根据业务规则识别对应的业务对象及属性。

分析业务规则申涉及的各类业务信息项，从业务角度识别业务对象及属性，在"业务规则"中使用到的业务对象用"#XXX"标识，属性则用"#XX业务对象.XX属性"标识。

在"关联业务对象属性"一列罗列出使用到的业务对象属性，若涉及多个业务对象属性，则换行罗列。

标注缺失的业务对象或属性。

在识别过程中若发现有缺失的，或认为可以新增的业务对象或属性、则在申请增加。

检查业务规则的完整性。

（2）工具功能

用业务语言按一定规范描述实现步骤的过程，业务规则必须通过归纳总结来提炼。业务规则需要去差异化，根据不同场景总结而来。图13示出了完善业务规则的示意图。

（3）交付物示例

图14示出了完善业务规则交付物示例的示意图。

3.分析领域对象

工序3.1：识别领域对象

（1）工艺方法

1）合并应用组件内所有任务/子交易工作事项：则以流程建模中的《工作事项定义清单》作为输入物，按应用组件划分确认的范围，汇总该应用组件下所有任务的工作事项（任务名称、工作事项序号、工作事项名称、工作事项规则、关联业务对象及属性），进行排序（按工作事项名+工作事项规则）。

2）识别每个工作事项的动作及应用组件归属：识别出每个工作事项所隐含的动作，动作以 动词 + ”_ ”+ 名词 的方式命名。建议将名词区分为实体+属性，以下划线分割。

3）对动作按业务目的进行提升（结合任务）：根据工作事项的业务目的，结合任务的表述，概述性描述工作事项的动作。描述的颗粒度比任务更细，但比工作事项的详细规则略微概要。

4）明确动作承接的业务规则内容：一个工作事项可以识别出多个动作，或是一个工作事项识别出一个动作，但动作也可只承接该工作事项的部分规则，故需要对动作承接的具体业务规则内容进行说明，便于后续设计。同时，识别出动作关联的业务对象及属性。

基于识别的动作，根据名称中的名词识别出业务概念（名词），作为领域对象名称。粒度不宜过细、避免以操作数据库表的方式思维。根据具有相同业务概念的动作，提炼出领域对象的行为和属性。领域对象必须包含：唯一名称、属性、行为。

（2）工具功能

根据识别出的产品特征，对特征下的可变要素、业务规则及其他考虑因素进行识别，一旦满足这类要求的可变要素，则作为备选产品条件。图15是识别对象分析的示意图。

（3）交付物示例

图16示出了识别对象分析交付物示例的示意图。

工序3.2：绘制领域对象关系图

（1）工艺方法

1）选定本应用组件内的领域对象作为绘制关系图的开始；

2）使用UML 类图表达领域对象间的关系，并遵循UML类图的绘制规范；关系类型为六选一，且允许反复推敲、达成共识后选择“无关系”（没有任何类型的连接线）。领域对象之间的关系有6种，强弱顺序为：继承 = 实现 > 组成 > 聚合 > 关联 > 依赖，图17示出了领域对象之间关系的示例图，详细如下：

继承：表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。

实现：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

组成：是整体与部分的关系，但部分不能离开整体而单独存在。

聚合：是整体与部分的关系，且部分可以离开整体而单独存在。

关联：是一种拥有的关系，它使一个类知道另一个类的属性和方法。

依赖：是一种使用的关系，即一个类的实现需要另一个类的协助。

3）以核心领域对象为中心、布局时考虑周边各区域尽量聚类；关系线上可用表达双边的数量对应关系。

（2）工具功能

梳理关键业务要素（实体）和关键行为的关系，形成领域对象关系图，如图18所示。用于承接业务需求，指导后续的系统设计。

（3）交付物示例

工序3.3：绘制领域对象时序图

（1）工艺方法

1)筛选任务：主要围绕核心领域对象、尽量涵盖并穿透领域对象周边的每一条关系线。

2)绘制领域对象关系验证时序图：涵盖本应用组件的领域对象关系图的关系线段的走向穿透，不追求从用户端到端视角考虑。使用UML序列图表达领域对象的时序关系，并遵循UML序列图的绘制规范。

3)根据推演调整领域对象的关系、行为，直至主要关系线全部被推演，同类分支关系尽量推演（不要求分支关系完全覆盖），通常覆盖全部的主要关系线或全部关系线的60%即可。

4)需要保证领域对象关系验证时序图、领域对象关系图和领域对象识别清单三者中的领域对象名称、行为名称必须一致。

（2）工具功能

选取子域范围内尽可能多的任务（不低于60%的覆盖率），对任务下子域内的领域对象之间的关系和调用顺序进行梳理，用以验证领域对象关系图中的领域对象及对象间关系的正确性。图19示出了领域对象时序图。

（3）交付物示例

4.聚合分析

工序4.1：聚合分析

（1）工艺方法

1）根据领域对象关系图中的关系线的强弱顺序，初步识别聚合。

继承、组成关系放在同一聚合内；

聚合关系根据业务紧密度决定是否放在一个聚合内，如果难以判断，则优先划分到不同的聚合内。

关联、依赖关系尽量不放在一个聚合内；

没有关系的不能放在一个聚合内；

2）从业务和技术实现两个视角来判断聚合拆开或合并的各自优劣势，并进行最终决策。

3）本阶段不考虑非功能需求。

4）定义聚合应遵循的五个原则如下：

同一聚合内，保持业务规则的一致性。业务规则的一致性（不变性），指同样的动作导致业务对象的状态变化和业务含义完全一致，即事务一致性（立即性、原子性）；单次事务只能同步修改聚合内的业务对象的状态等，并隔绝对其他聚合的修改。

只能通过唯一标识符引用其他聚合。聚合间的引用，均需通过聚合根的唯一标识，以根实体进行点状关联，避免形成网状关系。

聚合要设计得小巧；若发现聚合内的非根实体有生命周期，则拆为不同聚合。小巧的聚合便于简化复杂问题；便于迭代时灵活地拆分、组合；单一职责原则（SRP），避免聚合内想做的事情过多。

使用最终一致性更新其他聚合。因采用松耦合的异步机制，聚合外的事务一致性只需要最终一致，不需要实时强一致。同时，在银行业中，大量使用异步机制带来的副作用是否可控，有待进一步实践验证，因此暂将跨应用组件的事务，使用领域事件方式、实现最终一致性，解耦复杂长流程。

应用分析阶段暂不考虑非功能需求导致聚合的拆分、合并。分析阶段暂不考虑技术异构、性能要求等非业务功能需求。在设计阶段再考虑非功能需求导致的聚合拆分与合并。

5）识别聚合根：

在领域对象关系图中，一个聚合内处于关系最中心的实体就是聚合根；它表现为继承关系中被继承的对象，或组成/聚合关系中的枢纽。一个聚合只能有一个聚合根。

聚合根诞生或消亡，会引起其他实体同生死，或变得无意义。

6）关联和组合查询类的，暂不认定为 “同生死”范畴。

（2）工具功能

根据领域对象中的关系的强弱顺序 ，识别出聚合。 识别聚合方法：1、继承、组成关系尽量放在同一聚合内；2、聚合关系根据业务紧密度决定是否放在一个聚合内，如果难以判断，则优先划分到不同的聚合内；3、关联、依赖关系尽量不放在一个聚合内；4、没有关系的不能放在一个聚合内。图20为聚合分析的示意图。

（3）交付物示例

图21示出了聚合分析交付物示例的示意图。

5.用例分析

工序5.1：定义功能项

（1）工艺方法

1）在工作事项描述的颗粒度不大于任务的前提下（即，领域内的任务已被充分识别，任务下至少关联一个工作事项），考虑工作事项可以在不同任务间复用因素，基于应用组件范围内的全部工作事项、及其具体业务规则，进行标准化后，可能涉及拆分、更新属性、合并等情形，具体如图22所示。

2）定义功能项的操作注意事项如图23所示。

3）涉及前后映射关系的后续处理：定义功能项所影响的模型总体调整原则是不追溯调整前一阶段工作事项的成果、当前阶段同步调整映射关系、未来基于功能项后续处理。详见下述【】内的调整策略。

流程建模阶段，工作事项向上与任务存在关联关系；【前一阶段，不追溯调整】

分析建模阶段，

工作事项向下与业务规则存在关联关系，功能项与工作事项存在映射关系； 【当前阶段、追溯调整映射关系】

业务规则会使用产品条件、动名词、引用业务对象及关键属性；【当前阶段、追溯调整映射关系】

领域对象及其行为，与工作事项的业务规则存在映射关系；【当前阶段、追溯调整映射关系】

功能会包含一组工作事项；【下一工序、未来适用】

设计建模阶段，功能所包含的一组工作事项，粒度大于领域对象行为而小于功能的部分，会被设计为应用服务的一类可编排服务。【下一阶段、未来适用】

（2）工具功能

定义功能项，承上完善流程建模工作事项，以及分析建模的业务规则成果，启下为设计建模做好准备。图24为用例分析的示意图。

（3）交付物示例

图25示出了用例分析交付物示例的示意图。

工序5.2：识别功能

（1）工艺方法

1）承接功能项的分析成果，进一步分析应用组件内角色、时序连续的功能项，组成一个功能。

2）识别功能时不体现场景的差异，对于不同场景或不同活动下使用的同一个任务，功能识别的结果保持一致。

3）基于功能识别的成果产物《 xx活动(或交易)-功能识别清单》，将所有活动功能清单中的功能按照应用组件分别进行汇总去重。

（2）工具功能

如果需求为业务建模，通过对业务建模的分析，以任务为维度，基于cpcp因子以及其他因素的差异，识别出各任务所对应的功能。图26为识别功能的示意图。

（3）交付物示例

图27示出了识别功能交付物示例的示意图。

工序5.3：绘制用例工作流图

（1）工艺方法

1)用例选择：根据干系人触发不同场景的活动，按场景确定用例。

2)应用组件选择：选择本用例使用的功能对应的应用组件，作为绘图的泳道；

3)功能选择：将本用例使用的功能，放在相应的泳道对齐应用组件；

4)确定功能的主责编排方，作为流程串接的主体；

5)根据业务流程顺序，确定调用关系。

（2）工具功能

基于对业务模型的分析以及业务经验，对三级活动进行实例化，形成具体的用例。可以基于业务场景进行识别，一个场景识别为一个用例。充分理解用例的业务本质和交互流程，识别出用例所涉及的功能，以及功能间的串接流程，并进行流程图绘制，以便后续进行服务与分层架构的映射。图28为绘制用例工作流图的示意图。

（3）交付物示例

图29示出了绘制用例工作流图交付物示例的示意图。

6.应用分析成果

工序6.1：应用分析成果

（1）工艺方法

1）领域对象边界清单：根据前述工序确定的领域对象的聚合边界、应用组件边界，依次罗列出应用组件、及应用组件包含的所有聚合。

2）领域对象定义清单：根据领域对象归属的聚合，罗列出每个聚合包含的领域对象名称、类型、属性、行为。

3）功能清单：罗列前述工序确定的应用组件，应用组件包含的业务功能名称、描述、（对应的）任务名称、功能项序号、功能项名称、业务规则等。

（2）工具功能

根据上述各工作事项的成果，以应用组件为单位，将聚合、实体、动作（命令）的关系整理为领域对象定义清单。图30为应用分析成果的示意图。

（3）交付物示例

图31示出了应用分析成果交付物示例的示意图。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：在本发明的精神和原则之内，其依然可以对前述各实施例记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本发明的保护范围。

Claims (6)

1.一种分析建模方法，包括工艺方法论和工艺工具平台，原理是工艺工具平台承接工艺方法论，将工艺方法论的思想使用工艺工具平台进行体现；

所述的分析建模包括以下工序步骤：

1）定义应用组件；包括：1.1）定义应用组件，1.2）绘制应用组件全景图；其中，1.1）定义应用组件包括：若需求为业务建模需求，参考业务组件的划分，至少将一个业务组件预设为一个应用组件，后续迭代调整；若需求非业务建模需求，基于现状系统的模块划分、项目的规划以及行业经验、趋势判断进行预设，后续迭代；1.2）绘制应用组件全景图包括：参考业务领域、业务组件的图例、分层结构，根据应用组件清单，先进行分层框架设计，然后将相应的应用组件放在分层框架中，按应用组件的关联性，决定其摆放的远近位置；

2）完善业务规则；工艺方法包括完善业务规划，具体为整理业务规则，适配产品条件，引用业务对象/属性，检查规则完整性；

3）分析领域对象；包括：3.1）识别领域对象；3.2）绘制领域对象关系图；3.3）绘制领域对象时序图；

其中，3.1）识别领域对象的工艺方法包括：识别每个工作事项的动作及应用组件归属，结合任务对动作按业务目的进行提升，明确动作承接的业务规则内容，基于识别的动作，根据名称中的名词识别出业务概念，作为领域对象名称，根据具有相同业务概念的动作，提炼出领域对象的行为和属性，领域对象包含：唯一名称、属性、行为；

3.2）绘制领域对象关系图的工艺方法包括：选定本应用组件内的领域对象作为绘制关系图的开始；使用UML类图表达领域对象间的关系，并遵循UML类图的绘制规范；以核心领域对象为中心、布局时考虑周边各区域聚类；

4）聚合分析；包括：4.1）根据领域对象关系图中的关系线的强弱顺序，初步识别聚合；其中，强弱顺序为：继承=实现>组成>聚合>关联>依赖；4.2）从业务和技术实现两个视角来判断聚合拆开或合并的各自优劣势，并进行最终决策；

5）用例分析；包括：5.1）定义功能项，5.2）识别功能，5.3）绘制用例工作流图；其中，5.1）定义功能项包括：在工作事项描述的颗粒度不大于任务的前提下，考虑工作事项在不同任务间复用因素，基于应用组件范围内的全部工作事项、及其具体业务规则，进行标准化后，涉及拆分、更新属性、合并的情形；定义功能项的操作注意事项；涉及前后映射关系的后续处理；5.2）识别功能包括：承接功能项的分析成果，进一步分析应用组件内角色、时序连续的功能项，组成一个功能；识别功能时不体现场景的差异，对于不同场景或不同活动下使用的同一个任务，功能识别的结果保持一致；基于功能识别的成果产物，将所有活动功能清单中的功能按照应用组件分别进行汇总去重；5.3）绘制用例工作流图包括：用例选择：根据干系人触发不同场景的活动，按场景确定用例；应用组件选择：选择本用例使用的功能对应的应用组件，作为绘图的泳道；功能选择：将本用例使用的功能，放在相应的泳道对齐应用组件；确定功能的主责编排方，作为流程串接的主体；根据业务流程顺序，确定调用关系；

6）应用分析成果，包括：6.1）领域对象边界清单：根据前述工序确定的领域对象的聚合边界、应用组件边界，依次罗列出应用组件、及应用组件包含的所有聚合；6.2）领域对象定义清单：根据领域对象归属的聚合，罗列出每个聚合包含的领域对象名称、类型、属性、行为；6.3）功能清单：罗列前述工序确定的应用组件，应用组件包含的业务功能名称、描述、任务名称、功能项序号、功能项名称、业务规则。

2.如权利要求1所述的分析建模方法，其特征在于，其特征在于具体构思为：工艺方法论根据业务需求和边界划分原则，推导出最符合业务需求的操作过程。

3.如权利要求2所述的分析建模方法，其特征在于，所述的工艺方法论，具体包括三重构成边界，其特征在于：

第一重边界是应用组件；

第二重边界是针对应用组件来确定层级，使用分层架构划分为交易层，领域层，应用层、基础设施层；

第三重边界是针对领域层，做聚合设计。

4.如权利要求3所述的分析建模方法，其特征在于，第二重边界中，每个层级的定义如下：

交易层：将领域驱动设计分层架构中的“用户接口层”重新定义为“交易层”，负责交易服务/接口的定义，以及服务编排，对外提供服务；

应用层：依赖领域层，协调和编排各聚合，不包含业务规则，不保留业务对象的状态，但保有应用任务的进度状态，以领域服务的粒度提供支持；

领域层：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则；

基础设施层：提供仓储服务实现，数据实体的持久化。

5.如权利要求4所述的分析建模方法，其特征在于，所述的工艺工具平台，其设计有动名词库；平台用于承接上述工艺方法论，对上述工艺方法论的操作过程提供数字化管理能力，提供模型资产的管理能力，管理工艺中各工序的成果产物；旨在通过分析建模功能，能够承接业务建模的成果实现应用分析建模，为后续的应用设计提供支持。

6.如权利要求3所述的分析建模方法，其特征在于，其中：所述第三重边界中，将领域对象聚合在一起，形成聚合，作为隔离领域模型的最小单元。