项目式DDD实现的移动端航油加注系统设计

孙景荣，王健凯，吴 科

（西安电子科技大学 空间科学与技术学院，陕西 西安 710071）

0 引 言

经济全球化的发展趋势日益加快，人们在参加各种经济交流活动时也逐渐倾向于选择飞机等方便且快速的交通方式。这将促进我国航空产业的发展，航空燃油（简称“航油”）的需求也随之增加，民用机场的航油加注业务也因此高速增加[1]。为了提高民航系统航油业务的整体信息化，实现数据和信息共享，促进航油加注系统的智能化，本文以项目的方式设计了一个基于领域驱动设计（Domain-Driven Design,DDD）[2]的移动端航油加注系统。该系统基于DDD思想，采用C/S架构设计并实现了灵活可扩展的平板终端航油加注系统APP，改变了传统加油模式，提高了加油作业效率，使油单能够电子化，对机场的信息化、智能化管理以及推动民航产业的发展都具有重要意义。

1 系统总体流程

机场航油加注的总体作业流程如图1所示。具体步骤如下：（1）航空公司和空管中心的相关负责人生成加注航油的任务表；（2）机场的调度员在收到加油的任务表后，将任务下达给加油员；（3）加油员选择任务进行接收，并开始航油加注作业；（4）在进行加注作业的同时生成油单并签字；（5）将油单等信息同步至服务器。系统总体的业务功能要求能够实现自动接入、读取、整合油单相关数据；自动生成电子油单，自动上传、存储、打印油单。该系统能够提升开单效率与准确率；同时，油单的签字主要是电子签名的方式，以减少纸质方式造成的浪费。

图1 机场航油加注总体流程

2 系统领域建模及功能模块设计

2.1 系统离线业务模型设计

终端设备的网络信号会受到机场塔台无线电、飞机和塔台的雷达、乘客手机等设备连接基站等干扰，随时会出现断网离线情况。因此本系统在开发时考虑了离线业务模型。针对离线需求，航油加注系统需要在网络干扰较多或者无网络的情况下支持离线操作，在网络异常、通信干扰等不可抗因素造成的网络断开状态下完成加油任务，如能够进行离线生成任务表、离线修改油单、离线持久化油单等操作。在网络恢复后，再将保障进度数据与电子油单数据上传到系统后台。为此，本文提出了一种离线的加油方案用以解决离线断网情况下的加油问题。首先，系统在网络正常连接期间，可以缓存航班表和任务表到本地数据库。因此PAD（移动设备）在执行任务时因网络异常而断开连接，而又不得不进行离线作业之前，有过一次及以上的成功联网，就可以通过缓存的航班表及任务表进行离线作业。若在联网时没有需要缓存的任务，离线状态下任务表中没有任务，则进行离线的任务申请；若缓存了任务，并且任务表中有任务则接受离线任务，同时在本地Realm数据库中持久化任务表，在上述的作业过程均不断尝试与服务器进行连接。

如果PAD在进行加油作业之前无法成功联网，并且没有将任务表缓存至本地，则进行对航班的离线创建，通过PAD将航班信息持久化到本地的航班表，同时尝试与服务器连接并上传这些数据。如果要执行该航班的任务，在航班信息持久化后接受任务，否则在离线状态下申请创建任务，然后再将任务表持久化至本地，在此期间不断尝试连接服务器并将本地任务表同步至服务器。创建了加注任务，可以继续进行操作，如生成离线油单、离线录入油料、离线修改油单等操作，打印油单操作所需要的数据也能够生成，然后将油单信息持久化至本地。

最后在本地Realm数据库保存油单所需相关信息，如油料、油井等信息；并等待网络的恢复，在网络恢复后与服务器进行连接，在服务器的系统后台同步油单数据以及加油保障进度等信息。

2.2 系统领域模型设计

DDD是一种面向对象的软件开发方法论，强调将开发的重点放在解决业务领域问题上。这个方法论的思想首先是在进行开发时，需要领域专家的参与，将其经验和专业知识纳入进来，工作人员与专家将面向同一模型进行讨论，彼此共享知识与信息，防止需求走样，从而建立正确的领域模型；其次，通过领域模型作为软件开发的核心来进行指导，再通过代码来实现模型。因此，领域驱动设计的核心是建立正确的领域模型[3]。

根据对加油系统需求的分析，发现加油系统较为复杂，后期需要进行维护扩展，可以使用领域模型进行系统设计。建立领域模型，区分领域对象和领域对象之间的逻辑关系，分析系统中哪些实体是对象，哪些是值对象。由于系统逻辑较为复杂，给出部分领域模型如图2所示。

图2 系统领域模型类图

2.3 系统功能模块设计

根据前面的需求分析以及领域模型设计，系统整体的功能模块包括：人员登录、任务信息、航班信息、油单信息、人车绑定、导航栏信息等六大模块。功能框图如图3所示。

图3 系统功能框图

（1）人员登录模块：此模块可以注册加油员的账号，加油员可以使用账号和密码进行登录，在登录后也可退出系统，同时此模块有注销加油员账号的功能。

（2）任务信息模块：主要用于管理任务信息，包含任务列表、任务检索、任务详情、创建航班四部分，可以执行添加和取消任务、接受任务、结束任务等功能。

（3）航班信息模块：此模块用于管理航班信息，可以执行新增航班、查询航班、检索航班、订阅和取消航班等功能。

（4）油单信息模块：对油单进行编辑、修改，修改油单类型、加油油量等参数；具有对油单进行签名、录入油料信息等功能，并能够在有网络或者蓝牙连接时，连接至打印机，调用接口对打印机进行控制。

（5）人车绑定模块：在加油作业时，加油员需要绑定一辆加油车才能使用此加油车正常地给飞机加油，所以此模块用于加油员与加油车辆的绑定。加油员可以通过输入车牌号，专有的车辆识别号或者扫描加油车上面的二维码与车辆绑定。在任务结束后，加油员可以进行解绑操作，与加油车解除绑定。

（6）导航栏信息模块：该模块即为系统APP的导航栏，包含常用且重要的按钮供加油员快速查看所需信息，如警告、消息通知、个人信息等，设置了应急的通信窗口供加油员在发现紧急情况时快速联系相关人员。

3 系统分层架构设计

3.1 领域驱动设计的分层原则

DDD分层的基本原则是：（1）需要分离关注点，隔离地设计软件的不同部分；（2）某一层中元素不依赖其上层元素，而是与同层中的元素或者其相邻的下层元素有较高的耦合性；（3）向上的信息传递必须经过一些间接机制。分层是为了使系统分成几个部分，各个部分分工明确，只负责系统中的某个功能。这样有利于降低系统各功能之间的耦合性，提高功能内部的内聚性，且会使得软件的架构更加清晰，更有利于解释其设计的内容和目的。大多数成功的分层设计都可以使用DDD的经典分层架构来实现[4-8]。

3.2 React+Redux中的MVC设计模式

React和Redux都是前端框架，React是一个负责View层渲染的框架，其采用的Diff算法和虚拟DOM思想使得操作DOM时耗费效率方面的问题得到了有效的解决[9]。React Native框架是在React的基础上衍生出来的，可以兼顾优良的用户体验[10]。Redux是一个轻量级的数据层框架，可以使存储数据方式更为清晰，而且能够使应用更易调试[11]；同时，使用Redux框架可以在系统变得错综复杂时解决诸如重现问题或添加新功能困难的问题[12]。

React+Redux中的Model View Controller（MVC）模式是对传统MVC框架的细化，在Redux中Controller分为action和reducer，通过action去派发一个事件，然后在reducer里定义这个事件，对store中的state进行修改。Redux中store里的state表示Model，而React主要负责UI层的显示，里面的各个Component表示View。

3.3 基于DDD思想的MVC分层架构

DDD适合业务逻辑复杂的应用。其以系统业务建模为中心，可扩展性强，可以按照需求灵活地对软件进行设计，同时如果后续对系统的需求有所改动，可以较容易地进行修改或重构。基于React和Redux框架的MVC设计模式，与DDD相结合时可以结合它们的优点，规避缺点，比如MVC架构虽然有良好的可测试性，但在具有复杂业务逻辑的情况下表现不佳，二者结合既能保证有复杂业务逻辑的程序稳定运行，也能保留可测试性，为系统的测试提供了便利。二者的有机结合，使各层之间的功能划分明确，每一层能够单独测试，进一步提高了系统的可维护性和可扩展性[13-16]。系统的架构如图4所示。

图4 基于DDD思想的MVC分层架构

从MVC的角度上进行设计，系统被设计为User Interface（用户接口层）和Model（模型层）两层的架构。其中User Interface层细分为View（视图层）和Controller（控制层）。而Model又按照DDD思想进一步细化，分为Application（应用层）、Domain（领域层）和Infrastructure（基础结构层）。

（1）User Interface（用户接口层）

用户接口层面向用户，为了加油的工作人员而设计，加油员直接使用的视图层操作简单、功能齐全、界面简洁、响应快速。视图层在本系统中主要表现为页面的各个Component（组件）。控制层基于REST风格接口，用于前端APP与后端的对接，负责将用户的各种操作转换成针对后端的操作，将操作发送至Model层。

（2）Application（应用层）

应用层不含任何的业务逻辑操作，本身也没有业务逻辑代码，用于将用户接口层传递的业务进行封装、组合等，定义要完成的业务，将这些业务传递给领域层，并协调指挥领域层中各领域对象之间的操作，以及领域层与基础结构层之间的动作，以完成用户交给系统的任务。

（3）Domain（领域层）

领域层不仅是Model层的核心，也是整个系统的核心，系统在这一层完成几乎全部的业务逻辑；系统要准确地完成复杂的业务，需要对这一层的元素进行清晰明确的设计。Domain层包含Entity（实体）、Value Object（值对象）、Domain Event（领域事件）和Repository（仓储）等多种重要的领域组件。

（4）Infrastructure（基础结构层）

基础结构层为其他三层提供底层依赖操作。这一层与业务逻辑无关，包含着数据库、中间件等工具，由于系统数据持久化的需要，在该层下又分出了持久化层，系统在持久化层使用了Realm数据库、React-native-storage插件库等工具，将领域模型的状态存储至这一层，目的是保证领域层业务逻辑的纯净。

4 系统实现

根据前面系统需求分析和领域模型设计，移动端航油加注系统实现的主要业务功能有航班获取、任务获取、申请任务、油单生成、电子签名、同步数据、油单上传打印、离线创建航班、离线生成任务、接受任务、离线生成油单等核心业务功能。系统核心功能页面实现及功能测试如下：

（1）加油员在平板作业终端打开系统APP，根据后台提供的账号和密码进行登录，如图5所示；后台验证通过进入任务列表首页。

图5 系统登录页

（2）点击一条任务进行加油操作，图6为航班MU777的加油任务的详情页；加油员在确认任务信息无误后，可点击【接受任务】按钮，点击后任务状态变为到位确认，按钮状态即变为【到位确认】。

图6 MU777任务详情页

（3）点击【到位确认】后进入的页面为油单详情页，此时会读取加油数据，并显示出来，如图7所示。点击【生成油单】按钮，任务状态会变为上传油单，加油员在上传油单之前需要点击【签名】按钮，弹出电子签名窗口，加油员在此窗口签名，如图8所示。签名确认后点击【上传油单】，任务状态变为打印油单，点击【打印油单】后，PAD向车载主机和打印机发送打印指令，打印此油单。至此，一条完整的加油任务执行完毕。

图7 MU777任务生成油单信息

图8 对油单进行签名确认

（4）侧边栏内的其他按钮也能够进行操作。如点击侧边栏【航班】按钮，当日在加油员工作的机场的所有航班信息都会显示出来，提供航班检索功能，方便加油员快速定位航班。点击【新建航班】将离线创建航班，保存后成功添加到航班列表中。经测试，系统能够正常完成核心功能的操作。

5 结 语

本文首先详细分析了系统业务需求；其次通过需求设计系统功能，结合领域建模分析方法，更深层次地挖掘出项目核心需求，使得软件的设计更符合实际的需求。然后，基于领域驱动设计的分层架构思想，与MVC框架相结合，利用ES6语法、React Native移动端框架、React和Redux框架以及Android数据库框架Realm等新技术设计了系统的分层架构，有效地划分软件的层次设计，使系统各层之间的耦合程度得以下降，软件的开发效率和可维护性也得以提高。最后，实现了加油员平板终端操作的航油加注系统，使得机场加油作业方式从传统的人工操作到实现电子化、智能化控制成为了可能，对机场管理以及民航产业的现代化、信息化发展都具有重要意义。