CN116301760A - 用于软件开发的应用设计系统 - Google Patents

Abstract

本发明提供了一种用于软件开发的应用设计系统，包括概要设计模块和详细设计模块，其中，通过采用领域驱动设计的思想，在概要设计阶段，采用分层架构思想，将应用划分为四层，解决了三层架构在面对金融科技领域复杂业务体现出的各种问题，同时，采用领域边界划分策略，明确业务边界，来分离业务复杂度和技术复杂度，降低软件系统设计的复杂度。

Description

用于软件开发的应用设计系统

技术领域

本发明涉及应用设计技术领域，特别是一种用于软件开发的应用设计系统。

背景技术

软件的生命周期分为三个时期：软件定义、软件开发、运行维护，每个时期又分为若干个阶段，其中软件开发包括概要设计、详细设计、编码和单元测试，通常前两个阶段统称为应用设计，后两个阶段称为系统实现。

概要设计是发生在软件需求分析后的一种行为，其主要目的是基于软件需求规格说明书，把需求分析阶段得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及用户交互界面。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。一般概要设计采用的就是以上所述的模块化、功能分解方法和面向数据结构的设计方法。在设计系统架构时，传统的做法往往是基于“高内聚，低耦合”的思想，将应用按照三层架构来划分，分别为业务接口层、业务逻辑层和数据访问层。在数据结构设计时，主要考虑数据在数据库中如何存储，数据库表如何设计等因素。

概要设计完成后，进一步对概设阶段的内容进行细化，做详细设计，确定接口服务的实现、数据结构、功能模块的交互等等，输出详细设计说明书。

1）系统架构设计采用的三层架构，是一种数据驱动设计，自底向上的，面向数据的设计模式，业务逻辑层处于业务接口层和数据访问层的中间，如果业务接口层增加一个功能，为保证其设计符合分层结构的模式，需要在相应的业务逻辑层和数据访问层中都增加相应的代码，从而增加了开发成本。

2）三层架构中的业务逻辑层，对于数据访问层是调用者，对于业务接口层是被调用者，依赖和被依赖的关系全部放在业务逻辑层，那么解耦依赖关系则变得较为困难。

3）三层架构为了保证分层结构，业务逻辑层必须要通过数据访问层来访问数据库，则降低了系统性能。

4）三层架构是一种关注数据的架构模式，开发人员主要考虑数据在数据库中如何存放，这种方式会导致业务受限与数据结构的因素，导致无法实现或者实现困难等问题。

5）传统的应用设计文档通常采用visio、Word、Excel文档呈现，文档多，难以管理，而且文档的关联关系无法保证。

6）应用设计中涉及到的需求无法与需求规格说明书中的保持一定的映射关系，无法确认所有的需求是否在概要设计中完成了分析，而且需求的变更，引起的概要设计的变更，内容的同步无法及时响应。

7）应用设计阶段的工作对系统实现阶段的工作仅具备指导作用，工作成果无法渗透到代码实现阶段。

发明内容

鉴于上述问题，本发明提出一种克服上述问题或者至少部分地解决上述问题的用于软件开发的应用设计系统，目的在于基于应用分析阶段输出的模型或软件需求规格说明书等，从技术的角度给出实现的方案，该阶段包括两个部分，概要设计和详细设计。概要设计承接分析建模阶段的成果，按分层架构原则进行服务分层、并识别功能并分解为功能项，为后续的详细设计和代码落地进行顶层设计。详细设计承接概要设计成果，进一步细化，为生成代码框架和代码可落地奠定基础。

本发明提供了一种用于软件开发的应用设计系统，所述应用设计系统包括：

概要设计模块，采用分层架构的思想，基于目标软件的软件需求规格说明书将目标软件进行服务分层，得到包括交易层、应用层、领域层和基础设施层的服务分层结果；采用领域边界划分策略对领域服务层进行服务粒度细分；根据服务分层结果和服务粒度细分的结果执行概要设计。其中，目标软件是需要开发的软件，在进行开发前需要先获取到软件需求规格说明书。

详细设计模块，基于所述概要设计模块的概要设计结果进行详细设计实现代码开发，进而生成所述目标软件的代码框架。

可选地，所述概要设计模块包括服务分层设计、服务类设计、交易接口设计、数据库设计、批量设计；

所述服务分层设计包括：绘制领域对象功能时序图、服务分层、编制服务清单；

所述服务设计包括：应用层类设计、领域层类设计；

所述批量设计包括：日终批量、联机批量、定时批量。

可选地，所述服务分层设计进行服务分层采用的方法包括：

领域对象方法识别：包括聚合根方法、实体方法、值对象方法；

聚合根方法：时序图中从功能项或领域服务发出、聚合根对象返回的方法，以及聚合根实体对象自身的方法，识别为聚合根方法；

实体方法：时序图中从聚合根发出、实体对象返回的方法，以及实体对象自身方法，识别为实体方法；

值对象方法：时序图中从实体对象发出、值对象返回的方法，以及值对象自身的方法，识别为值对像方法。

可选地，所述服务设计中的领域层类设计包括：领域服务类设计、领域对象类设计。

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

可选地，所述数据库设计的数据库为关系型数据库；

一个领域对象初步识别为一个数据表，表名称使用领域对象名称，以此为基础根据领域对象之间的关系进行调整；领域对象的属性识别为表字段；领域对象的唯一标识识别为表的主键，建立唯一索引。

可选地，所述概要设计模块执行批量设计的方法包括：

识别批量任务，批量任务的类型包括：联机批量、定时批量、日终批量；

确定所有批量任务的主责应用组件；

确定不同批量任务类型的个性化信息。

可选地，所述详细设计模块执行数据对象设计、服务类详细设计、批量详细设计：其中，

针对概要设计模块识别出的服务类做详细设计，包括但不限于类的基础信息、属性信息、类的方法；

对数据对象进行设计，根据业务要素的关联性、紧密性归纳抽象、简单数据对象POJO，根据各服务层类数据交互需要定义数据传输对象DTO；

对批量任务进行详细设计，包括日终、定时、联机批量交易的定义以及流程的编排。

数据对象：一组数据属性的集合，是一种结构化的表达。通常作为服务或方法的输入输出参数，包括DTO、POJO。DTO：数据传输对象（Data Transfer Object），DTO用于不同服务或方法之间的数据交互。POJO：简单数据对象（Plain Ordinary Java Object），特指对关系紧密的业务属性进行归类抽象，形成可复用的业务属性集合。

可选地，服务类详细设计包括：领域对象详细设计、领域服务详细设计、仓储服务详细设计、应用服务详细设计。

可选地，所述领域对象详细设计包括类基础信息定义、类属性定义、类方法定义。

本发明采用“工艺方法论+工艺工具”的方式，RADC工艺方法论借鉴了领域驱动设计的思想。工具承接RADC工艺方法论，进一步将其思想使用工具进行体现，命名为RADC工艺平台-应用设计。应用设计中主要采用了领域驱动设计的分层架构思想，由应用组件承接应用划分的单元，将应用组件划分为交易层、应用服务层、领域服务层、基础设施层四个主要层次。同时采用领域边界划分策略，对领域层进行服务粒度细分。工具承接设计建模工艺的成果，识别出交易服务、应用服务、领域服务、仓储服务（基础设施层）等，同时根据领域对象，以聚合为单位做数据库表设计，以及初步定义批量任务，完成概要设计阶段的主要内容。详细设计是针对概要设计阶段的内容进一步细化，如对概要设计识别出的类做详细设计，包括类的基础信息、属性信息、类的方法等；对数据对象进行设计，根据业务要素的关联性、紧密性归纳抽象POJO对象，根据各服务层类数据交互需要定义DTO数据对象；同时对批量任务进行详细设计，包括日终、定时、联机批量交易的定义以及流程的编排。

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

应用设计阶段，向上承接分析建模阶段的成果，向下指导开发编码阶段的代码实现。

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

如图1~2所示，传统的三层架构，以业务子系统为单元，将业务应用划分为业务接口层、业务逻辑层和数据访问层。在DDD中，在限界上下文内，使用分层架构划分为：业务接口层、应用层、领域层和基础设施层，形成限界上下文的最小隔离。基于以上边界划分策略，传统的三层架构和DDD的四层架构，分别将业务子系统和限界上下文边界，使用分层策略，将其划分为三层和四层。图1示出了三层架构和DDD的四层架构对比示意图，图2示出了DDD中的领域边界划分策略图。

在传统的开发模式下，将架构分为三层，分别为业务接口层、业务逻辑层、数据访问层。

传统的开发模式是数据驱动设计的一种模式，是面向数据，自底向上的思路，主要关注数据，在开发速度上有一定优势，但是，如果系统的业务变化速度较快，从长远来看，必定存在以下问题：

1）新需求的开发越来越难，代码较难扩展；

2）代码维护越来越难，一个功能涉及到的代码改动量较大；

3）技术创新越来越难，代码重构难度越来越大；

4）测试越来越难，一个功能涉及到的代码较多，导致一个小功能的改动，就需要大面积功能的回归测试。

金融科技领域的系统，往往业务模块较多，业务流程较为复杂，业务系统之间的高度关联性也增加了复杂度，因此，传统的三层架构模式，应对这类复杂系统的需求变更以及业务迭代时，便会体现出一定的局限性。除此之外，随着硬件设备和软件技术的发展，软件架构也发生了很大的变化，从单体架构到集中式架构，再到当今和未来一段时期优势将更加突出的微服务架构。微服务解决了集中式架构的软件不能快速响应需求的变化等等单体应用的很多问题，但是又导致了过去一段时期经常出现的新问题，例如：微服务拆分不考虑业务需求的边界、微服务单纯从技术视角考虑而过度拆分或不合理拆分等等问题。

因此，领域驱动设计DDD的优势便体现出来了，领域驱动设计DDD就是为了解决这些问题而存在，从一个软件系统的长期价值来看，就是得需要领域驱动设计DDD，虽然从设计到开发需要成本，但是随着时间的增长，代码一直可以保持整洁，利于扩展和维护，高度自治，高度内聚，边界领域划分的很清楚，总体来看，领域驱动设计DDD是一种领域驱动设计，自顶向下，同时关注业务活动的设计模式。

领域驱动设计DDD分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。在本发明中，在DDD的边界划分策略的基础上进一步做了改造，去除了子域和限界上下文的边界，整合为应用组件。本发明中，在应用组件内，使用分层架构划分为交易层，领域层，应用层、基础设施层，形成以应用组件为单元的物理边界。

图4示出了领域驱动设计中的分层架构图。

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

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

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

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

图5示出了本发明实施例的服务分层架构图。

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

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

领域层（DMS）：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则。实体由聚合根编排，聚合根的方法被识别为聚合服务，供领域服务和应用服务直接调用。

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

聚合：由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化，领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。聚合根：如果把聚合比作组织，那聚合根就是这个组织的负责人，聚合根也称为根实体，它不仅是实体，还是聚合的管理者和对外接口人。

本发明通过采用领域驱动设计的思想，在概要设计阶段，采用分层架构思想，将应用划分为四层，解决了三层架构在面对金融科技领域复杂业务体现出的各种问题，同时，采用领域边界划分策略，明确业务边界，来分离业务复杂度和技术复杂度，降低软件系统设计的复杂度。应用设计承接分析建模阶段的成果，进一步对功能进行落地设计，详细设计阶段，逻辑严密，遵循重设计轻开发的原则，以及自下而上的设计顺序，按照调用关系自底向上进行设计，先领域层，再应用层的设计顺序。工艺工具承接工艺方法论，解决了传统的线下文档协同管理难等问题，形成具备良好操作性的工具，以便应对需求的灵活分析及承接，模型资产的规范化管理，以及应用设计阶段的数字化管理。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了三层架构和DDD的四层架构对比示意图；

图2示出了DDD中的领域边界划分策略图；

图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示出了本发明实施例交易接口设计交付物示例的示意图；

图32示出了本发明实施例数据库设计的界面示意图；

图33a~33c示出了本发明实施例数据库设计交付物示例的示意图；

图34示出了本发明实施例数据库实体E-R图交付物示例的示意图；

图35示出了本发明实施例批量设计日终批量的界面示意图；

图36示出了本发明实施例批量设计联机批量的界面示意图；

图37示出了本发明实施例批量设计定时批量的界面示意图；

图38示出了本发明实施例批量设计日终批量交付物示例的示意图；

图39示出了本发明实施例批量设计联机批量交付物示例的示意图；

图40示出了本发明实施例批量设计定时批量交付物示例的示意图；

图41示出了本发明实施例DTO定义、使用与工程间的依赖关系示意图；

图42示出了本发明实施例POJO的定义与使用与工程间的依赖关系示意图；

图43示出了本发明实施例数据对象设计的界面示意图；

图44示出了本发明实施例数据对象设计（DTO）的交付物示例的示意图；

图45示出了本发明实施例数据对象设计（POJO）的交付物示例的示意图；

图46示出了本发明实施例服务类详细设计界面的示意图；

图47a~47b示出了本发明实施例领域对象详细设计交付物示例的示意图；

图48示出了本发明实施例领域服务详细设计交付物示例的示意图；

图49示出了本发明实施例仓储服务详细设计交付物示例的示意图；

图50 a~50b示出了本发明实施例应用服务详细设计交付物示例的示意图；

图51示出了本发明实施例批量详细设计日间批量的界面示意图；

图52示出了本发明实施例批量详细设计日终批量的界面示意图；

图53示出了本发明实施例批量详细设计批量交易定义的界面示意图；

图54示出了本发明实施例批量详细设计日间批量交付物示例的示意图；

图55示出了本发明实施例批量详细设计日终批量（换日前）交付物示例的示意图；

图56示出了本发明实施例批量详细设计日终批量（换日）交付物示例的示意图；

图57示出了本发明实施例批量详细设计日终批量（换日后）交付物示例的示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

在本实施例中，目标软件可以是需要设计并创建的满足用户业务需要的任意一款软件。目标软件的应用设计包括概要设计和详细设计两部分，概要设计承接应用分析建模阶段的成果，将功能进行分解，按应用架构进行概要设计落地，其工序包括服务分层设计、服务类设计、交易接口设计、数据库设计、批量设计。详细设计承接概要设计成果，将概要设计做进一步的细化，其工序包括数据对象设计、服务类详细设计、批量详细设计。

应用设计的主要工序共计13道，概要设计10道工序，详细设计3道工序，详细说明如图6~图7所示。

应用设计阶段工序成果物清单如下表所示。

一、概要设计

1. 服务分层设计

服务分层设计的主要工序包括：绘制领域对象功能时序图；服务分层；编制服务清单。

工序1：绘制领域对象功能时序图

（1）工艺方法

1)根据《xx应用组件-功能清单》，按功能分别绘制；

2)根据《xx应用组件-领域对象定义清单》、《xx-应用组件-领域对象关系图》，对功能涉及的领域对象方法行为进行串接；

功能下的每个功能项对应一个方法，按功能项的时序进行绘制；

与聚合无关的功能项、涉及同一聚合根多个实例协作的功能项、涉及多个聚合的功能项，以上三类功能项识别要通过领域服务进行编排。领域服务如果访问聚合也必须通过聚合根；

功能项只能通过聚合根访问聚合下实体的方法;

值对象的方法需要通过值对象所属的实体对象访问。

（2）工艺工具

以应用分析功能的维度绘制领域对象功能时序图，梳理该功能下领域对象及领域对象行为之间的依赖关系，是服务分层的前提。领域对象时序图的要素应包含功能、功能项、领域服务、领域对象等。图8示出了绘制领域对象功能时序图的界面示意图。

工具菜单路径：应用设计->概要设计->服务分层设计->领域对象功能时序图

（3）交付物示例

图9示出了绘制领域对象功能时序图交付物示例的示意图。

工序2：服务分层

（1）工艺方法

1)领域对象方法识别：包括聚合根方法、实体方法、值对象方法；

聚合根方法：时序图中从功能项或领域服务发出、聚合根对象返回的方法，以及聚合根实体对象自身的方法，识别为聚合根方法；

实体方法：时序图中从聚合根发出、实体对象返回的方法，以及实体对象自身方法，识别为实体方法；

值对象方法：时序图中从实体对象发出、值对象返回的方法，以及值对象自身的方法，识别为值对像方法。图10示出了领域对象方法识别的示意图。

2)领域服务的识别

时序图中由功能项（参与者生命线）发出、领域服务生命线返回的方法识别为一个领域服务。图11示出了领域服务识别的示意图。

3)应用服务的识别：每个功能识别为一个应用服务，即一张图体现了一个应用服务编排。图12示出了应用服务识别的示意图。

（2）工艺工具

依据每个功能的领域对象时序图将时序图中的服务划分到领域层和应用层。领域层的服务包括领域对象的方法和领域服务，应用层的服务包括应用服务。服务之间存在依赖关系，识别服务需要从下向上的方向进行识别。图13示出了服务分层界面的示意图。

工具菜单路径：应用设计->概要设计->服务分层设计->服务分层

（3）交付物示例，参见图14~图16。

工序3：服务清单

（1）工艺方法

1)领域对象方法清单：按聚合、领域对象分别进行汇总；

2)领域服务清单

汇总应用组件的所有领域服务；

分析是否存在不同功能识别出的同名不不同义领域服务，如果同义则认为是同一领域服务；如果不同义，从名称上分开，并从绘制领域功能时序图开始迭代更新。

分析是否存在不同功能识别出的同义不同名的领域服务，如果存在，则合并为一个领域服务，并从绘制领域功能时序图开始迭代更新；

3)应用服务：汇总应用组件的所有领域服务；

（2）工艺工具

通过识别领域对象方法、识别领域服务、识别应用服务后，形成服务清单。图17示出了本发明实施例服务清单的界面示意图。

工具菜单路径：应用设计->概要设计->服务分层设计->服务清单

（3）交付物示例

服务清单工序的交付物与服务分层工序的交付物是一样的。如图18~图20所示。

2、服务类设计

工序1：应用层类设计

（1）工艺方法

1)按应用服务逐一进行设计，承接应用分析对应的功能；

2)根据接口隔离原则，每个应用服务识别一个接口类和一个实现类；

3)每个类识别一个基础方法和多个渠道适配方法；

4)应用服务类无属性；

5)应用服务类通过角色进行管理；

6)角色的识别原则；

角色按应用组件识别，不同应用组件有不同的角色，每个应用组件至少有一个角色。

角色是抽象的，具有相对的稳定性，便于后续应用服务的扩展。

角色必须职责明确、边界清晰，应用组件中每个应用服务都归属于某一角色。

7)角色识别方法；

将应用服务进行汇总。

将应用服务根据业务目的相似性、功能项的相似性、功能连续性进行分类抽象，识别出承接角色。

（2）工艺工具

将某一应用组件的应用层服务和领域层的服务进行归类划分，应用层的类主要为应用服务类，同时还有角色管理，领域层的类包括领域服务类、仓储服务类和领域对象类。类的设计采用自下向上的设计原则，先进行领域层类设计再进行应用层类设计，类之间存在依赖、聚合、关联、实现、继承的关系。图21示出了本发明实施例应用层类设计的界面示意图，图22示出了本发明实施例应用层类设计的界面示意图。

工具菜单路径：应用设计->概要设计->服务类设计->应用层类

（3）交付物示例，如图23~24所示。

工序2：领域层类设计

（1）工艺方法

1)领域服务类设计

将概要设计服务分层梳理出的领域服务进行汇总；

将领域服务进行分类：如果领域服务数量较少，一个应用组件可以只有一个类承接所有领域服务；如果领域服务数量较多，可以按领域服务的类型、是否承接功能项、业务目的、涉及聚合等维度进行分类。

将领域服务按分类依据进行划分，每个领域服务识别为类的一个方法。

领域服务类无属性。

2)领域对象类设计

每个领域对象识别为一个类；

将领域对象的方法识别为类的方法；

领域对象的属性识别为类属性；

（2）工艺工具，图25示出了本发明实施例领域层类设计的界面示意图。

工具菜单路径：应用设计->概要设计->服务类设计->领域层类

（3）交付物示例，如图26~图29所示。

3、交易接口设计

工序1：交易接口设计

（1）工艺方法

1)根据应用分析中每个用例识别交易服务。

2)参考原系统交易进行交易的输入输出接口定义，所有接口字段需要进行贯标。例如，可以把存量系统现有交易的输入输出，作为设计建模接口定义的参考。

3)根据用例流图对应用服务进行编排。

（2）工艺工具

依据应用分析的用例分析交易服务，应用分析的一个用例可根据不同的渠道设计不同的交易服务。一个交易服务包括对交易输入输出接口信息的设计和交易服务的编排。交易服务的输入输出信息来源于对任务输入输出的分析，交易服务的编排依据用例流图中功能的串接。图30示出了本发明实施例交易接口设计的界面示意图。

工具菜单路径：应用设计->概要设计->交易接口设计

（3）交付物示例，图31示出了本发明实施例交易接口设计交付物示例的示意图。

4、数据库设计

工序1：数据库设计

（1）工艺方法

1）数据库特指关系型数据库，不考虑非关系型数据库设计。

2）考虑到技术实现，不允许一个数据对象由多个数据库表承接。

3）一个领域对象初步识别为一个数据表，表名称使用领域对象名称，以此为基础根据领域对象之间的关系进行调整（合并、拆分）；

4）领域对象的属性识别为表字段；

5）领域对象的唯一标识识别为表的主键，建立唯一索引。

（2）工艺工具

依据应用分析领域对象关系图进行数据库表的设计，原则一个领域对象设计一张表。根据领域对象之间的数量关系(领域对象的数量关系包括，一对一、一对多、多对一、多对多、继承等)对数据库表进行合并或关联形成数据库表的关系。数据库表设计也支持不依据领域对象对表进行增加、修改和删除操作，支持对数据库表的字段和索引的增加修改和删除的操作。图32示出了本发明实施例数据库设计的界面示意图。

工具菜单路径：应用设计->概要设计->数据库设计

（3）交付物示例，如图33a~图34所示。

5、批量设计

工序1：批量设计

（1）工艺方法

1）识别批量任务，并确定批量任务的类型（联机批量、定时批量、日终批量）；

2）确定所有批量任务的主责应用组件；

3）确定不同批量任务类型的个性化信息。

日终批量任务的执行区间：换日前、换日、换日后；

联机批量任务的触发联机交易；

定时批量任务的执行方式：按频率、按时点。

（2）工艺工具

依据对现有系统的梳理、对需求的分析、业务事件的分析，梳理出涉及批量交易的清单，批量设计包括联机批量、日终批量、定时批量的设计。批量设计重点是梳理交易的清单，为详细设计提供设计的基础。如图35~图37所示。

工具菜单路径：应用设计->概要设计->批量设计

（3）交付物示例，如图38~图40所示。

二、详细设计

1、数据对象设计

工序1：数据对象设计

（1）工艺方法

本工序完成对POJO及DTO两种数据对象数据结构的定义。

1)POJO

POJO是从业务角度对业务要素集合的抽象，可用于数据的传递及数据的复用。

POJO的属性定义

数据类型可以是基础类型或嵌套POJO，POJO嵌套不超过两次（三层）；

当数据类型是基础类型时，需要按数据标准进行贯标；

POJO的属性应该密切相关，这些属性组合在一起才能表达完整含义；

POJO只有数据没有行为

POJO颗粒度要适度，如果太大影响复用性，太小无法完整体现业务。

2)DTO

DTO原则上不复用，以减少数据变化带来的影响。

DTO的属性定义

数据类型可为基础类型或POJO，基础类型需要按数据标准进行贯标；

DTO不能包含DTO；

DTO如果包含POJO，只允许嵌套一次（DTO-POJO）（包含的POJO中不能再包含POJO）；

DTO只有数据没有行为。

DTO中能用于各层服务及方法的输入输出，原则上不复用（接口与实现除外）；

3)DTO与POJO的定义与使用

同层间可以使用；

存在工程依赖关系的可以使用，即能看到就能使用；

1．实践经验

1)POJO根据业务经验进行总结与抽象，如果有以往项目成果，可在项目成果基础上不断进行迭代；如果没有参考成果，可先定义DTO，然后在DTO基础上结果经验将总是在一起使用、关系紧密、业务目的一致的业务要素抽象成POJO。

2)DTO用于方法的输入输出，所有DTO并不是一次定义完成，而是在定义方法的输入输出时根据分析的具体需要交互进行的。在所有类方法输入输出设计完成后，可汇总进行分析，对相似DTO进行合并。

3)DTO定义、使用与工程间的依赖关系。例如交易层依赖于应用API层、应用实现层依赖于应用API层和领域层、基础设施层依赖于领域层，则其定义与使用关系如图41所示。

4)POJO的定义与使用也取决于工程间的依赖关系。例如交易层依赖于应用API层，应用实现层依赖于应用API层和领域层，公共层的POJO可以被所有工程使用。则其定义与使用关系如图42所示。

（2）工艺工具

1）、根据业务要素的关联性、紧密性归纳抽象POJO数据对象；

2）、根据各服务层类数据交互需要定义DTO数据对象。如图43所示。

工具菜单路径：应用设计->详细设计->数据对象设计

（3）交付物示例，如图44~图45所示。

2、服务类详细设计

工序1：服务类详细设计

服务类详细设计的主要包括：

领域对象详细设计；

领域服务详细设计；

仓储服务详细设计；

应用服务详细设计；

（1）工艺方法

领域对象详细设计：

1)类基础信息定义

领域对象类的工程类型为“领域层”；工程类型：代码工程结构的分层。描述不同概要设计中各服务在系统架构中的落地工程层级。例如交易服务层、应用服务API层、应用服务实现层、领域服务层、基础设施层。

应用组件、聚合、服务类类型、实现/接口名称、继承父类名称、类中文名称继承概要设计信息；

定义类英文名称，命名规则符合编码规范要求；

2)类属性定义

领域对象类必须定义属性，在应用分析成果的领域对象关键属性基础上进行补充和调整。

属性类型：

“基础类型”属性必须根据数据标准贯标；

“数据对象”属性必须是已定义的POJO数据对象；

“类”属性指所持有的其他值对象类，例如账户状态之于账户。

“其他”指不包含在以上三种类型的属性，例如map；

3)类方法定义

方法定义之前必须完成依赖的其他领域对象方法定义。

方法类型

公有方法：概要设计中识别出的供外部调用的方法；

私有方法：概要设计中识别出的内部使用方法及根据详细设计需要增加的私有方法；

构造方法：根据创建对象需要而识别出的构造方法。

get/set方法：领域对象类默认保留get/set方法，在成果中无需体现。get/set的使用原则：仓储服务中可以直接使用get/set方法；set方法在应用服务、领域服务中创建对象时可以使用，其他情况原则上不允许使用；get方法允许在领域服务使用；

方法输入输出

方法输入：可为单个数据对象（DTO或POJO），或基础类型及POJO数据对象的数据集合，但数据集合项不能超过4个，否则要定义为DTO；

方法输出：可以没有输出项或有一个输出项，该输出项可以是布尔型、基础类型、数据对象（DTO或POJO）；

方法与依赖方法的输入输出必须匹配。每个依赖方法的输入项均可在定义方法输入或其他依赖方法输出中找到数据源；方法的输出项可以在依赖方法的输出项中找到数据源;

方法处理逻辑

应体现概要设计中识别出的所有依赖的领域对象方法；

必须明确方法的输入输出及所调用依赖方法的输入输出转换关系；

3. 领域服务详细设计：

1)类基础信息定义

领域服务类的工程层级为“领域层”。

应用组件、聚合、服务类类型、实现/接口名称、继承父类名称、类中文名称继承概要设计信息。

定义类英文名称，命名规则参见编码规范。

2)类方法定义

领域服务类方法定义之前必须完成依赖的领域对象方法或领域服务的定义。

方法类型

公有方法：概要设计中识别出的对外提供服务；

私有方法：根据详细设计实现需要增加的私有方法；

方法输入输出

方法输入：可为单个数据对象（DTO或POJO），或基础类型及POJO数据对象的数据集合，但数据集合项不能超过4个，否则要定义为DTO；

方法输出：可以没有输出项或只有一个输出项，该输出项可以是布尔型、基础类型、数据对象（DTO或POJO）；

方法与依赖方法的输入输出必须匹配。每个依赖方法的输入项均可在定义方法输入或其他依赖方法输出中找到数据源；方法的输出项可以在依赖方法的输出项中找到数据源;

方法处理逻辑

应体现概要设计识别出的所有依赖聚合根实体方法及其他领域服务的使用；

必须明确方法的输入输出及所依赖领域对象方法的输入输出转换关系；

领域服务允许使用DO的get/set方法，但set方法只允许在创建DO时使用；

DO：领域对象（Domain Object），从现实中抽象出来业务实体，如实体对象和值对象，既包含数据，也包含具有领域业务逻辑的行为。

4. 仓储服务详细设计：

1)设计原则

仓储服务接口在领域层定义，接口实现在基础设施层，接口实现一一对应；

每个聚合有两个仓储接口类:

查询类：面向查询交易，以获取数据为目的，数据转换PO-->POJO；PO：持久对象（Persistence Object），由一组属性和属性的get和set方法组成，PO对应数据库中的记录，一条记录就是一个PO对象，PO的每个属性对应数据库表的某个字段。

处理类：面向业务处理，以构造或持久化对象为目的，数据转换DO<--->PO；

仓储服务可以在应用层的事项类或领域层的领域服务、实体使用；

领域对象允许多次按需创建，相应的仓储服务提供不同的方法。

仓储服务中允许使用DO的get/set方法。

2)识别方法

逐一分析应用服务及领域服务对领域对象的使用要求，识别出创建对象和持久化对象的仓储服务方法；

对服务方法进行合并、去重，并按仓储服务的用途分为查询类和处理类；

3)仓储类基础信息定义

仓储服务接口类的工程层级为“领域层”、仓储服务实现类的工程层级为“基础设施层”；

应用组件、聚合、服务类类型、实现/接口名称、继承父类名称、类中文名称按实际情况进行填写。

定义类英文名称，命名规则参见编码规范。

4)类方法定义

查询类仓储方法输入输出

方法输入：可为单个数据对象（DTO或POJO），或基础类型及POJO数据对象的数据集合，但数据集合项不能超过4个，否则要定义为DTO；

方法输出：可以没有输出项或只有一个输出项，该输出项可以是布尔型、基础类型、数据对象（DTO或POJO）;

处理类仓储方法输入输出

方法输入：可为单个数据对象（DTO或POJO或DO），或基础类型及POJO数据对象的数据集合，但数据集合项不能超过4个，否则要定义为DTO；

方法输出：可以没有输出项或只有一个DO输出项;

方法处理逻辑

应体现DO与PO之间转换关系；

应用服务详细设计：

1)类基础信息定义

应用服务接口类的工程层级为“应用API层”，应用服务实现类的工程层级为“应用实现层”。

应用组件、服务类类型、实现/接口名称、继承父类名称、类中文名称继承概要设计信息。

定义类英文名称，命名规则参见编码规范。

2)类方法定义

方法定义之前必须完成依赖的领域层服务及方法的定义。

方法类型

公有方法：概要设计中识别出的实现应用服务的基础方法及按渠道识别的适配方法；

私有方法：根据详细设计实现需要增加的私有方法；

方法输入输出

应用服务接口类方法与对应实现类的方法输入输出一致；

方法输入：必须为一个DTO数据对象；

方法输出：可以没有返回或返回一个DTO数据对象；

方法与依赖方法的输入输出必须匹配。每个依赖方法的输入项均可在定义方法输入或其他依赖方法输出中找到数据源；方法的输出项可以在依赖方法的输出项中找到数据源;

方法处理逻辑

详细描述对依赖方法（领域服务或聚合根方法）的编排；

描述对领域对象（聚合根）的创建与存储；

明确方法的输入输出与依赖方法输入输出的转换关系；

（2）工艺工具

根据概要设计识别出的类，对类进行详细设计，包括以下内容：1）、类基础信息：包括类名称、工程层级、类修饰等信息；2）、类的属性信息：领域对象类的类属性；3）、类的方法：类方法的名称、修饰、输入输出、处理规则。图46示出了本发明实施例服务类详细设计界面的示意图。

工具菜单路径：应用设计->详细设计->服务类详细设计

（3）交付物示例，如图47a~图50b所示。

3、批量详细设计

工序1：批量详细设计

（1）工艺方法

1)将每个批量任务按实现需要识别为不同应用组件承接的批量交易（批量作业）。

2)对每个批量交易进行定义。

基础信息

批量交易码：遵循统一的编码规则，是批量交易的唯一标识。

批量交易名称：能够体现批量交易的用途、目的。

批量类型：交易批量（拆分）、交易批量（不拆分）、读文件批量、写文件批量。

应用组件：承接批量交易的应用组件，可以与批量任务应用组件不同。

执行信息

执行序号：批量任务下各批量交易的执行顺序，序号小的先执行，序号相同并发执行。

执行条件：只有满足该条件时才执行此批量交易。

依赖批量交易：只有依赖交易执行后才能执行此批量交易；

数据拆分信息

数据拆分字段：数据需要并发处理时，通过此项指定拆分依据；

数据拆分逻辑：数据拆分规则，拆分后的数据可以并发；

事务提交笔数：处理完指定笔数后系统自动进行事务提交；

处理逻辑

正常处理：批量交易正常业务处理规则描述及依赖的应用服务、错误信息；

作业前处理逻辑：批量交易正常处理前的处理规则描述；

作业后处理逻辑：批量交易正常处理后的处理规则描述；

异常处理：批量交易正常处理失败时的处理规则描述；

3)将批量交易按执行顺序、依赖关系进行编排。

4)分别对日终三个阶段（换日前、换日、换日后）的批量任务按执行顺序、依赖关系进行编排；

三个阶段分别进行编排，编排目标为概要设计识别出的日终批量任务；

每个批量任务编制执行序号，序号小的先执行，序号相同并发执行；

当前批量任务的前序批量任务即为依赖批量任务，只有所有依赖批量任务全部执行完成后当前批量任务才会执行；

可以指定批量任务失败后的处理机制：终止或跳过；

（4）工艺工具

1）、日间批量设计：包括联机批量、定时批量的详细设计。将每个批量任务分解为多个批量交易，进行批量交易流程编排。对每个批量交易的执行信息、数据拆分信息、处理逻辑、文件信息等进行详细定义。2）、日终批量设计：对日终按换日前、换日、换日后三个阶段进行批量任务的流程编排；将每个批量任务分解为多个批量交易，进行批量交易流程编排。对每个批量交易的执行信息、数据拆分信息、处理逻辑、文件信息等进行详细定义。如图51~图53所示。

工具菜单路径：应用设计->详细设计->批量详细设计

（3）交付物示例，如图54~图57所示。

本发明实施例提供的用于软件开发的应用设计系统采用领域驱动设计中架构分层策略，形成了本发明中的服务分层架构，包括交易层、 应用层、领域层和基础设施层。借鉴领域驱动设计中领域边界划分策略，进一步改造，形成本发明中的领域边界划分策略。从分析建模阶段分析出的聚合，识别出应用服务、领域服务及交易接口。交易接口定义时，编排应用服务的方法。做数据库设计时，以领域对象模型为基础，通过数据库表满足领域对象持久化的要求，领域对象与数据库表之间通过仓储服务进行解耦。批量任务的识别，包括日终批量、联机批量和定时批量。

本发明实施例通过采用领域驱动设计的思想，在概要设计阶段，采用分层架构思想，将应用划分为四层，解决了三层架构在面对金融科技领域复杂业务体现出的各种问题，同时，采用领域边界划分策略，明确业务边界，来分离业务复杂度和技术复杂度，降低软件系统设计的复杂度。应用设计承接分析建模阶段的成果，进一步对功能进行落地设计，详细设计阶段，逻辑严密，遵循重设计轻开发的原则，以及自下而上的设计顺序，按照调用关系自底向上进行设计，先领域层，再应用层的设计顺序。工艺工具承接工艺方法论，解决了传统的线下文档协同管理难等问题，形成具备良好操作性的工具，以便应对需求的灵活分析及承接，模型资产的规范化管理，以及应用设计阶段的数字化管理。

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

Claims (10)

1.一种用于软件开发的应用设计系统，其特征在于，所述应用设计系统包括：

概要设计模块，采用分层架构的思想，基于目标软件的软件需求规格说明书将目标软件进行服务分层，得到包括交易层、应用层、领域层和基础设施层的服务分层结果；采用领域边界划分策略对领域服务层进行服务粒度细分；根据服务分层结果和服务粒度细分的结果执行概要设计；

详细设计模块，基于所述概要设计模块的概要设计结果进行详细设计实现代码开发，进而生成所述目标软件的代码框架。

2.根据权利要求1所述的应用设计系统，其特征在于，

交易层：主要负责，交易服务/接口的定义，以及服务编排，对外提供服务；

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

领域层：聚焦业务对象的业务逻辑实现，负责表达业务概念、业务状态和业务规则；实体由聚合根编排，聚合根的方法被识别为聚合服务，供领域服务和应用服务直接调用；

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

3.根据权利要求1所述的应用设计系统，其特征在于，所述概要设计模块包括服务分层设计、服务类设计、交易接口设计、数据库设计、批量设计；

所述服务分层设计包括：绘制领域对象功能时序图、服务分层、编制服务清单；

所述服务类设计包括：应用层类设计、领域层类设计；

所述批量设计包括：日终批量、联机批量、定时批量。

4.根据权利要求3所述的应用设计系统，其特征在于，所述服务分层设计进行服务分层采用的方法包括：

领域对象方法识别：包括聚合根方法、实体方法、值对象方法；

聚合根方法：时序图中从功能项或领域服务发出、聚合根对象返回的方法，以及聚合根实体对象自身的方法，识别为聚合根方法；

实体方法：时序图中从聚合根发出、实体对象返回的方法，以及实体对象自身方法，识别为实体方法；

值对象方法：时序图中从实体对象发出、值对象返回的方法，以及值对象自身的方法，识别为值对像方法。

5.根据权利要求3所述的应用设计系统，其特征在于，所述服务设计中的领域层类设计包括：领域服务类设计、领域对象类设计。

6.根据权利要求3所述的应用设计系统，其特征在于，所述数据库设计的数据库为关系型数据库；

一个领域对象初步识别为一个数据表，表名称使用领域对象名称，以此为基础根据领域对象之间的关系进行调整；领域对象的属性识别为表字段；领域对象的唯一标识识别为表的主键，建立唯一索引。

7.根据权利要求3所述的应用设计系统，其特征在于，所述概要设计模块执行批量设计的方法包括：

识别批量任务，并确定批量任务的类型，批量任务的类型包括：联机批量、定时批量、日终批量；

确定所有批量任务的主责应用组件；

确定不同批量任务类型的个性化信息。

8.根据权利要求3-7中任一项所述的应用设计系统，其特征在于，所述详细设计模块执行数据对象设计、服务类详细设计、批量详细设计：其中，

针对概要设计模块识别出的服务类做详细设计，包括类的基础信息、属性信息、类的方法；

对数据对象进行设计，根据业务要素的关联性、紧密性归纳抽象、简单数据对象POJO，根据各服务层类数据交互需要定义数据传输对象DTO；

对批量任务进行详细设计，包括日终、定时、联机批量交易的定义以及流程的编排。

9.根据权利要求8所述的应用设计系统，其特征在于，服务类详细设计包括：领域对象详细设计、领域服务详细设计、仓储服务详细设计、应用服务详细设计。

10.根据权利要求9所述的应用设计系统，其特征在于，所述领域对象详细设计包括类基础信息定义、类属性定义、类方法定义。

Images