一种分析建模方法技术

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

【技术实现步骤摘要】
一种分析建模方法


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

技术介绍

[0002]金融科技领域软件系统的复杂度主要体现在业务的复杂性和变化性，以及技术的复杂性和响应速度，金融科技领域的业务模块多，业务流程复杂，业务系统之间的高度关联性也加剧了复杂度，同时业务的发展、演变较快，业务边界的重组（拆分、合并）比较频繁。因此与之相对应的应用系统边界，也要快速响应和匹配业务边界的重组。
[0003]除此之外，随着硬件设备和软件技术的发展，软件架构也发生了很大的变化，从单体架构到集中式架构，再到当今和未来一段时期优势将更加突出的分布式微服务架构。微服务解决了集中式架构的软件不能快速响应需求的变化等等单体应用的很多问题，但是又导致了过去一段时期经常出现的新问题，例如：微服务的拆分不考虑业务需求的边界、微服务单纯从技术视角考虑而过度拆分或不合理拆分等等。
[0004]传统软件工程的应用系统边界若遇到业务边界的重组，存在着承接和映射关系不清晰、重构或改造困难、响应速度慢等问题。应用系统的边界和微服务的拆分不考虑业务需求的边界、微服务单纯从技术视角考虑而过度拆分或不合理拆分等问题。业务逻辑的复杂度与技术实现的复杂度混淆在一起，难以划分业务逻辑与技术实现的边界。业务人员与技术人员，语言不统一，导致需求的理解存在一定的偏差。

技术实现思路

[0005]本专利技术的目的主要解决以上
技术介绍
的问题。
[0006]针对
技术介绍
所存在的问题，我们采用“工艺方法论+工艺工具平台”的方式来解决以上问题，RADC工艺方法论借鉴了领域驱动设计的思想，并对部分概念重定义。工具承接RADC工艺方法论，进一步将其思想使用工具进行体现，命名为RADC工艺
‑
分析建模。
[0007]RADC工艺及工具可以解决以下问题：1）RADC工艺方法论重顶层设计，重工艺过程，轻开发编码，根据业务需求和边界划分原则，自然推导出最符合业务需求的结果。
[0008]2）借鉴领域驱动设计DDD的思想，通过领域、聚合等边界来分离业务复杂度和技术复杂度，来降低软件系统设计的复杂度；例如：子域将领域进一步分解、限界上下文将子域进一步分解、聚合将限界上下文进一步分解细化。本专利技术中去掉了限界上下文和子域，保留了领域、聚合，并使用“应用组件”来替代限界上下文和子域，使用领域模型中的业务需求等
相关知识进行抽象而形成应用组件。
[0009]3）RADC工艺将业务需求中使用自然语言编写的业务流程，从面向过程转变为面向对象，据此识别领域对象、划分边界、分析用例和识别功能。
[0010]4）工具承载了上述应用边界划分考虑业务边界的承接关系、面向对象的特点，以及重顶层设计、轻开发编码的思想。
[0011]5）工具对上述RADC工艺方法论的操作过程提供数字化管理能力，提供模型资产的管理能力，管理工艺中各工序的成果产物。解决了大量使用表格、绘图、文字的线下管理方式带来的更新困难、关联关系复杂等问题。
[0012]6）工具设计了动名词库，用于解决业务人员与技术人员语言不统一的问题，真正实现了业技融合的理念。
[0013]本专利技术借鉴领域驱动设计DDD的思想，通过领域驱动设计过程，引用架构分层策略，领域驱动的四重边界分析等技术，在此基础上做进一步的重定义。下面依次来介绍各技术点。
[0014]战略设计：领域驱动设计在战略设计层面，从业务视角出发使技术人员专注于问题域，从领域专家那里获得领域见解，通过模块划分建立领域服务边界，通过限界上下文明确服务的职责。
[0015]战术设计：领域驱动设计在战术设计层面，从技术的视角出发，根据通用语言对单个限界上下文进行领域建模，提炼有效的业务模型，实施领域建模、架构设计完成软件的落地。
[0016]本专利技术中采用战略设计和战术设计来完成领域驱动设计，如图1所示，战略设计明确做什么的问题，战术设计明确怎么做，分别从业务的视角专注于问题域，通过应用组件来划分领域服务，通过聚合来明确领域服务边界，从技术视角，实体和值对象用于对具有不同领域特征的领域对象进行建模；聚合将一组领域对象绑定为一个整体，以控制事务；服务则充当领域模型的接口，具有无状态的特点；而资源库则用于封装领域对象的数据库访问操作。
[0017]如图2所示，领域驱动设计中利用四重边界进行架构设计：分而治之 ：DDD通过规划四重边界，把领域知识做了合理的固化和分层。领域中有核心子域和支撑子域、通用子域，子域中又拆分成多个限界上下文（BC），一个限界上下文中又根据领域知识核心与否进行分层，领域层中按照多个业务（子域）的强相关性形成一个聚合。
[0018]【第一重边界】确定愿景与目标，确定问题空间，确定核心子领域、通用子领域（多个子领域可以复用）、支撑子领域（额外功能）；【第二重边界】解决子域里的限界上下文，就是一道进程隔离层面的物理边界；【第三重边界】每个限界上下文内，使用分层架构划分为：接口层、领域层、应用层、基础设施层，形成限界上下文的最小隔离；【第四重边界】领域层里为了保证各个领域的完整性和一致性，引入聚合的设计作为隔离领域模型的最小单元。
[0019]本专利技术中根据领域驱动设计的四重边界设计架构的方式，进一步做了改造，去除
了子域和限界上下文的边界，整合为应用组件，如图3所示。两种方式定义应用组件，一种是业务建模需求，承接一个或者多个业务组件，预设为应用组件，另一种是非业务建模需求，基于现状系统的模块划分、行业经验以及业务发展趋势预设应用组件，后续迭代优化。在应用组件内，使用分层架构划分为交易层，领域层，应用层、基础设施层，领域层，保证业务的完整性和一致性，将领域对象聚合在一起，形成聚合，作为隔离领域模型的最小单元。
[0020]图4示出了领域驱动设计中的分层架构，包括：用户接口层：负责向用户展现信息以及解释用户命令。
[0021]应用层：应用层是领域层的上层，依赖领域层，是各聚合的协调和编排，原则上是不包括任何业务逻辑，不保留业务对象的状态，但它保有应用任务的进度状态。它以较粗粒度的封闭为前端接口提供支持。
[0022]领域层：领域层聚焦业务对象的业务逻辑实现，体现现实世界业务的逻辑变化。它用来表达业务概念、业务状态和业务规则。
[0023]基础设施层：作为其它层的支撑库存在，提供层间的通信，实现对业务对象的持久化，为其他任意层提供服务，为了解决耦合的问题，采用依赖倒置原则。
[0024]本专利技术对领域驱动设计中的分层架构进行了改进提出了一种服务分层架构，如图5所示，包本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种分析建模方法，包括工艺方法论和工艺工具平台，原理是工艺工具平台承接工艺方法论，将工艺方法论的思想使用工艺工具平台进行体现。2.如权利要求1所述的分析建模方法，其特征在于，其特征在于具体构思为：工艺方法论根据业务需求和边界划分原则，推导出最符合业务需求的操作过程。3.如权利要求2所述的分析建模方法，其特征在于，所述的工艺方法论，具体包括三重构成边界，其特征在于：第一重边界是应用组件；第二重边界是针对应用组件来确定层级，使用分层架构划分为交易层，领域层，应用层、基础设施层；第三重边界是针对领域层，做聚合设计。4.如权利要求3所述的分析建模方法，其特征在于，第二重边界中，每个层级的定义如下：交易层：将领域驱动设计分层架构中的“用户接口层”重新定义为“交易层”，主要负责，交易服务/接口的定义，以及服务编排，对外提供服务；应用层：依赖领域层，协调和编排各聚合，不包含业务规则，不保留业务对象的状态，但保有应用任务的进度状态，以领域服务的粒度提供支持；领域层：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则；基础设施层：提供仓储服务实现，数据实体的持久化。5.如权利要求4所述的分析建模方法，其特征在于，所述的工艺工具平台，其设计有动名词库；平台用...

【专利技术属性】
技术研发人员：许华山，吴限权，雷涛，牛国义，林挺，杨文峰，刘妍，杨雄，刘云星，曹安康，肖佳，
申请(专利权)人：深圳市长亮科技股份有限公司，
类型：发明
国别省市：