項目式DDD實現的移動端航油加注系統(tǒng)設計

孫景榮，王健凱，吳 科

（西安電子科技大學 空間科學與技術學院，陜西 西安 710071）

0 引 言

經濟全球化的發(fā)展趨勢日益加快，人們在參加各種經濟交流活動時也逐漸傾向于選擇飛機等方便且快速的交通方式。這將促進我國航空產業(yè)的發(fā)展，航空燃油（簡稱“航油”）的需求也隨之增加，民用機場的航油加注業(yè)務也因此高速增加[1]。為了提高民航系統(tǒng)航油業(yè)務的整體信息化，實現數據和信息共享，促進航油加注系統(tǒng)的智能化，本文以項目的方式設計了一個基于領域驅動設計（Domain-Driven Design,DDD）[2]的移動端航油加注系統(tǒng)。該系統(tǒng)基于DDD思想，采用C/S架構設計并實現了靈活可擴展的平板終端航油加注系統(tǒng)APP，改變了傳統(tǒng)加油模式，提高了加油作業(yè)效率，使油單能夠電子化，對機場的信息化、智能化管理以及推動民航產業(yè)的發(fā)展都具有重要意義。

1 系統(tǒng)總體流程

機場航油加注的總體作業(yè)流程如圖1所示。具體步驟如下：（1）航空公司和空管中心的相關負責人生成加注航油的任務表；（2）機場的調度員在收到加油的任務表后，將任務下達給加油員；（3）加油員選擇任務進行接收，并開始航油加注作業(yè)；（4）在進行加注作業(yè)的同時生成油單并簽字；（5）將油單等信息同步至服務器。系統(tǒng)總體的業(yè)務功能要求能夠實現自動接入、讀取、整合油單相關數據；自動生成電子油單，自動上傳、存儲、打印油單。該系統(tǒng)能夠提升開單效率與準確率；同時，油單的簽字主要是電子簽名的方式，以減少紙質方式造成的浪費。

圖1 機場航油加注總體流程

2 系統(tǒng)領域建模及功能模塊設計

2.1 系統(tǒng)離線業(yè)務模型設計

終端設備的網絡信號會受到機場塔臺無線電、飛機和塔臺的雷達、乘客手機等設備連接基站等干擾，隨時會出現斷網離線情況。因此本系統(tǒng)在開發(fā)時考慮了離線業(yè)務模型。針對離線需求，航油加注系統(tǒng)需要在網絡干擾較多或者無網絡的情況下支持離線操作，在網絡異常、通信干擾等不可抗因素造成的網絡斷開狀態(tài)下完成加油任務，如能夠進行離線生成任務表、離線修改油單、離線持久化油單等操作。在網絡恢復后，再將保障進度數據與電子油單數據上傳到系統(tǒng)后臺。為此，本文提出了一種離線的加油方案用以解決離線斷網情況下的加油問題。首先，系統(tǒng)在網絡正常連接期間，可以緩存航班表和任務表到本地數據庫。因此PAD（移動設備）在執(zhí)行任務時因網絡異常而斷開連接，而又不得不進行離線作業(yè)之前，有過一次及以上的成功聯網，就可以通過緩存的航班表及任務表進行離線作業(yè)。若在聯網時沒有需要緩存的任務，離線狀態(tài)下任務表中沒有任務，則進行離線的任務申請；若緩存了任務，并且任務表中有任務則接受離線任務，同時在本地Realm數據庫中持久化任務表，在上述的作業(yè)過程均不斷嘗試與服務器進行連接。

如果PAD在進行加油作業(yè)之前無法成功聯網，并且沒有將任務表緩存至本地，則進行對航班的離線創(chuàng)建，通過PAD將航班信息持久化到本地的航班表，同時嘗試與服務器連接并上傳這些數據。如果要執(zhí)行該航班的任務，在航班信息持久化后接受任務，否則在離線狀態(tài)下申請創(chuàng)建任務，然后再將任務表持久化至本地，在此期間不斷嘗試連接服務器并將本地任務表同步至服務器。創(chuàng)建了加注任務，可以繼續(xù)進行操作，如生成離線油單、離線錄入油料、離線修改油單等操作，打印油單操作所需要的數據也能夠生成，然后將油單信息持久化至本地。

最后在本地Realm數據庫保存油單所需相關信息，如油料、油井等信息；并等待網絡的恢復，在網絡恢復后與服務器進行連接，在服務器的系統(tǒng)后臺同步油單數據以及加油保障進度等信息。

2.2 系統(tǒng)領域模型設計

DDD是一種面向對象的軟件開發(fā)方法論，強調將開發(fā)的重點放在解決業(yè)務領域問題上。這個方法論的思想首先是在進行開發(fā)時，需要領域專家的參與，將其經驗和專業(yè)知識納入進來，工作人員與專家將面向同一模型進行討論，彼此共享知識與信息，防止需求走樣，從而建立正確的領域模型；其次，通過領域模型作為軟件開發(fā)的核心來進行指導，再通過代碼來實現模型。因此，領域驅動設計的核心是建立正確的領域模型[3]。

根據對加油系統(tǒng)需求的分析，發(fā)現加油系統(tǒng)較為復雜，后期需要進行維護擴展，可以使用領域模型進行系統(tǒng)設計。建立領域模型，區(qū)分領域對象和領域對象之間的邏輯關系，分析系統(tǒng)中哪些實體是對象，哪些是值對象。由于系統(tǒng)邏輯較為復雜，給出部分領域模型如圖2所示。

圖2 系統(tǒng)領域模型類圖

2.3 系統(tǒng)功能模塊設計

根據前面的需求分析以及領域模型設計，系統(tǒng)整體的功能模塊包括：人員登錄、任務信息、航班信息、油單信息、人車綁定、導航欄信息等六大模塊。功能框圖如圖3所示。

圖3 系統(tǒng)功能框圖

（1）人員登錄模塊：此模塊可以注冊加油員的賬號，加油員可以使用賬號和密碼進行登錄，在登錄后也可退出系統(tǒng)，同時此模塊有注銷加油員賬號的功能。

（2）任務信息模塊：主要用于管理任務信息，包含任務列表、任務檢索、任務詳情、創(chuàng)建航班四部分，可以執(zhí)行添加和取消任務、接受任務、結束任務等功能。

（3）航班信息模塊：此模塊用于管理航班信息，可以執(zhí)行新增航班、查詢航班、檢索航班、訂閱和取消航班等功能。

（4）油單信息模塊：對油單進行編輯、修改，修改油單類型、加油油量等參數；具有對油單進行簽名、錄入油料信息等功能，并能夠在有網絡或者藍牙連接時，連接至打印機，調用接口對打印機進行控制。

（5）人車綁定模塊：在加油作業(yè)時，加油員需要綁定一輛加油車才能使用此加油車正常地給飛機加油，所以此模塊用于加油員與加油車輛的綁定。加油員可以通過輸入車牌號，專有的車輛識別號或者掃描加油車上面的二維碼與車輛綁定。在任務結束后，加油員可以進行解綁操作，與加油車解除綁定。

（6）導航欄信息模塊：該模塊即為系統(tǒng)APP的導航欄，包含常用且重要的按鈕供加油員快速查看所需信息，如警告、消息通知、個人信息等，設置了應急的通信窗口供加油員在發(fā)現緊急情況時快速聯系相關人員。

3 系統(tǒng)分層架構設計

3.1 領域驅動設計的分層原則

DDD分層的基本原則是：（1）需要分離關注點，隔離地設計軟件的不同部分；（2）某一層中元素不依賴其上層元素，而是與同層中的元素或者其相鄰的下層元素有較高的耦合性；（3）向上的信息傳遞必須經過一些間接機制。分層是為了使系統(tǒng)分成幾個部分，各個部分分工明確，只負責系統(tǒng)中的某個功能。這樣有利于降低系統(tǒng)各功能之間的耦合性，提高功能內部的內聚性，且會使得軟件的架構更加清晰，更有利于解釋其設計的內容和目的。大多數成功的分層設計都可以使用DDD的經典分層架構來實現[4-8]。

3.2 React+Redux中的MVC設計模式

React和Redux都是前端框架，React是一個負責View層渲染的框架，其采用的Diff算法和虛擬DOM思想使得操作DOM時耗費效率方面的問題得到了有效的解決[9]。React Native框架是在React的基礎上衍生出來的，可以兼顧優(yōu)良的用戶體驗[10]。Redux是一個輕量級的數據層框架，可以使存儲數據方式更為清晰，而且能夠使應用更易調試[11]；同時，使用Redux框架可以在系統(tǒng)變得錯綜復雜時解決諸如重現問題或添加新功能困難的問題[12]。

React+Redux中的Model View Controller（MVC）模式是對傳統(tǒng)MVC框架的細化，在Redux中Controller分為action和reducer，通過action去派發(fā)一個事件，然后在reducer里定義這個事件，對store中的state進行修改。Redux中store里的state表示Model，而React主要負責UI層的顯示，里面的各個Component表示View。

3.3 基于DDD思想的MVC分層架構

DDD適合業(yè)務邏輯復雜的應用。其以系統(tǒng)業(yè)務建模為中心，可擴展性強，可以按照需求靈活地對軟件進行設計，同時如果后續(xù)對系統(tǒng)的需求有所改動，可以較容易地進行修改或重構?；赗eact和Redux框架的MVC設計模式，與DDD相結合時可以結合它們的優(yōu)點，規(guī)避缺點，比如MVC架構雖然有良好的可測試性，但在具有復雜業(yè)務邏輯的情況下表現不佳，二者結合既能保證有復雜業(yè)務邏輯的程序穩(wěn)定運行，也能保留可測試性，為系統(tǒng)的測試提供了便利。二者的有機結合，使各層之間的功能劃分明確，每一層能夠單獨測試，進一步提高了系統(tǒng)的可維護性和可擴展性[13-16]。系統(tǒng)的架構如圖4所示。

圖4 基于DDD思想的MVC分層架構

從MVC的角度上進行設計，系統(tǒng)被設計為User Interface（用戶接口層）和Model（模型層）兩層的架構。其中User Interface層細分為View（視圖層）和Controller（控制層）。而Model又按照DDD思想進一步細化，分為Application（應用層）、Domain（領域層）和Infrastructure（基礎結構層）。

（1）User Interface（用戶接口層）

用戶接口層面向用戶，為了加油的工作人員而設計，加油員直接使用的視圖層操作簡單、功能齊全、界面簡潔、響應快速。視圖層在本系統(tǒng)中主要表現為頁面的各個Component（組件）?？刂茖踊赗EST風格接口，用于前端APP與后端的對接，負責將用戶的各種操作轉換成針對后端的操作，將操作發(fā)送至Model層。

（2）Application（應用層）

應用層不含任何的業(yè)務邏輯操作，本身也沒有業(yè)務邏輯代碼，用于將用戶接口層傳遞的業(yè)務進行封裝、組合等，定義要完成的業(yè)務，將這些業(yè)務傳遞給領域層，并協調指揮領域層中各領域對象之間的操作，以及領域層與基礎結構層之間的動作，以完成用戶交給系統(tǒng)的任務。

（3）Domain（領域層）

領域層不僅是Model層的核心，也是整個系統(tǒng)的核心，系統(tǒng)在這一層完成幾乎全部的業(yè)務邏輯；系統(tǒng)要準確地完成復雜的業(yè)務，需要對這一層的元素進行清晰明確的設計。Domain層包含Entity（實體）、Value Object（值對象）、Domain Event（領域事件）和Repository（倉儲）等多種重要的領域組件。

（4）Infrastructure（基礎結構層）

基礎結構層為其他三層提供底層依賴操作。這一層與業(yè)務邏輯無關，包含著數據庫、中間件等工具，由于系統(tǒng)數據持久化的需要，在該層下又分出了持久化層，系統(tǒng)在持久化層使用了Realm數據庫、React-native-storage插件庫等工具，將領域模型的狀態(tài)存儲至這一層，目的是保證領域層業(yè)務邏輯的純凈。

4 系統(tǒng)實現

根據前面系統(tǒng)需求分析和領域模型設計，移動端航油加注系統(tǒng)實現的主要業(yè)務功能有航班獲取、任務獲取、申請任務、油單生成、電子簽名、同步數據、油單上傳打印、離線創(chuàng)建航班、離線生成任務、接受任務、離線生成油單等核心業(yè)務功能。系統(tǒng)核心功能頁面實現及功能測試如下：

（1）加油員在平板作業(yè)終端打開系統(tǒng)APP，根據后臺提供的賬號和密碼進行登錄，如圖5所示；后臺驗證通過進入任務列表首頁。

圖5 系統(tǒng)登錄頁

（2）點擊一條任務進行加油操作，圖6為航班MU777的加油任務的詳情頁；加油員在確認任務信息無誤后，可點擊【接受任務】按鈕，點擊后任務狀態(tài)變?yōu)榈轿淮_認，按鈕狀態(tài)即變?yōu)椤镜轿淮_認】。

圖6 MU777任務詳情頁

（3）點擊【到位確認】后進入的頁面為油單詳情頁，此時會讀取加油數據，并顯示出來，如圖7所示。點擊【生成油單】按鈕，任務狀態(tài)會變?yōu)樯蟼饔蛦?，加油員在上傳油單之前需要點擊【簽名】按鈕，彈出電子簽名窗口，加油員在此窗口簽名，如圖8所示。簽名確認后點擊【上傳油單】，任務狀態(tài)變?yōu)榇蛴∮蛦?，點擊【打印油單】后，PAD向車載主機和打印機發(fā)送打印指令，打印此油單。至此，一條完整的加油任務執(zhí)行完畢。

圖7 MU777任務生成油單信息

圖8 對油單進行簽名確認

（4）側邊欄內的其他按鈕也能夠進行操作。如點擊側邊欄【航班】按鈕，當日在加油員工作的機場的所有航班信息都會顯示出來，提供航班檢索功能，方便加油員快速定位航班。點擊【新建航班】將離線創(chuàng)建航班，保存后成功添加到航班列表中。經測試，系統(tǒng)能夠正常完成核心功能的操作。

5 結 語

本文首先詳細分析了系統(tǒng)業(yè)務需求；其次通過需求設計系統(tǒng)功能，結合領域建模分析方法，更深層次地挖掘出項目核心需求，使得軟件的設計更符合實際的需求。然后，基于領域驅動設計的分層架構思想，與MVC框架相結合，利用ES6語法、React Native移動端框架、React和Redux框架以及Android數據庫框架Realm等新技術設計了系統(tǒng)的分層架構，有效地劃分軟件的層次設計，使系統(tǒng)各層之間的耦合程度得以下降，軟件的開發(fā)效率和可維護性也得以提高。最后，實現了加油員平板終端操作的航油加注系統(tǒng)，使得機場加油作業(yè)方式從傳統(tǒng)的人工操作到實現電子化、智能化控制成為了可能，對機場管理以及民航產業(yè)的現代化、信息化發(fā)展都具有重要意義。