微服務時代，領域驅動設計在攜程國際火車票的實踐

一、前言

領域驅動設計（Domain-Driven Design，簡稱 DDD）是一種軟件開發設計思想，其旨在以領域為核心，讓軟件系統在實現時准確地基於對真實業務過程的建模，專注於業務問題域的需要。

DDD將軟件系統設計分為了2個部分：戰略設計和戰術設計，戰略設計用於提煉問題域並塑造應用程序的架構，戰術設計用於幫助創建用於復雜有界上下文的有效模型。基於此，DDD強調專注於核心領域，通過協作對公共語言和知識進行提煉，並且持續致力於領域的知識提煉，讓模型持續發展。

本文基於DDD思想，在攜程國際火車票中台預訂系統項目進行實踐。

 

二、實踐背景

本文以國際火車票中台預訂系統項目的創單流程為例，其服務結構下圖所示：

偽代碼如下所示：

@Overrideprotected CreateOrderResponse execute(CreateOrderRequest request) {    // 1、參數校驗    if (!validate(request)) {        throw new BusinessException(P2pBookingResultCode.PARAM);    }    if (orderMapper.select(request.getOrderId()) != null) {        throw new BusinessException(P2pBookingResultCode.ORDER_EXISTS);    }        // 2、初始化訂單    OrderDao orderDao = new OrderDao();    orderDao.setOrderId(request.getOrderId());    orderDao.setOrderStatus(100);    orderMapper.insert(orderDao);    // 初始化乘客信息    PassengerDao passengerDao = new PassengerDao();    ...    passengerMapper.insert(passengerDao);        // 3、轉換匯率    ExchangeRate exchangeRate = exchangeService.getExchangeRate(originCurrency, targetCurrency);        // 4、購買保險    if (isBuyInsurance(request)) {        // 調用保險服務        InsuranceInfo insuranceInfo = insuranceService.buyInsurance(request);        // 保存保險信息        InsuranceDao insuranceDao = new InsuranceDao();        ...        insuranceMapper.insert(insuranceDao);    }        // 5、供應商創單    SupplierOrder supplierOrder = supplierService.createOrder(request, exchangeRate);    // 保存供應商訂單信息    SupplierOrderDao supplierOrderDao = new SupplierOrderDao();    ...    supplierOrderMapper.insert(SupplierOrderDao);        // 6、保存訂單信息    orderDao = new orderDao();    orderDao.setOrderId(request.getOrderId);    orderDao.setOrderStatus(OrderStatusEnum.WAIT_FOR_PAY.getCode());    ...    orderMapper.update(orderDao);        // 7、發送超時支付取消消息    messageProducer.push(MessageQueueConstants.TOPIC_TIMEOUT_CANCEL, "orderId", String.valueOf(orderDao.getOrderId()), appSettingProp.getTimeoutMinutes(), TimeUnit.MINUTES);        // 8、返回結果    return mappingResponse(orderDao, orderInsuranceEntity, exchangeRateResponse);}

2.1 控制層臃腫

在傳統的互聯網軟件架構中，通常都會采用MVC三層架構，其是一種古老且經典的軟件設計模式，基於分層架構的思想，將整個程序分為了Model、View和Controller三層：

• Model（模型層）：最底下一層，是核心的數據，也就是程序需要操作的數據或信息；

• View（視圖層）：最上面一層，直接面向最終用戶的視圖，它是提供給用戶的操作界面，是程序的外殼；

• Controller（控制層）：中間的一層，就是整個程序的邏輯控制核心，它負責根據視圖層輸入的指令選取數據層的數據，然后對其進行相應操作產生最終結果；

MVC三層架構模式，將軟件架構分為了三層，就可以讓軟件實現模塊化，使三層相互獨立，修改外觀或者變更數據都不需要修改其他層，方便了維護和升級。但是這種軟件架構中模型層只關注數據，控制層只關注行為，隨着迭代的不斷演化，業務邏輯越來越復雜，便會導致整個控制層的代碼量越來越多，而模型層和視圖層的變更卻很少，最終導致整個控制層變得十分臃腫，從而失去了分層的意義。

 

2.2 過度耦合

在業務初期，程序的功能都非常簡單，此時系統結構邏輯是清晰的，但是隨着程序的不斷迭代，一方面會導致業務邏輯越來越復雜，系統逐漸冗余，模塊之間彼此關聯，軟件架構設計模式逐漸向“大泥球”模式（BBoM，Big Ball of Mud）發展；另一方面系統會調用越來越多的第三方服務，從而導致數據格式不兼容，業務邏輯無法復用。

在出票系統中，除了訂單相關的功能外，還包括了保險、匯率、供應商訂單等多個服務接口，同時包括保險、供應商訂單、乘客等多個模塊的功能及存儲均耦合在出票流程的控制層中，使得我們在維護代碼時，修改一個模塊的功能可能會影響到其他功能模塊。

另一方面，如匯率服務這種第三方接口也會存在結構不穩定的情況，當其API簽名發生變化或者服務不可靠需要尋找其他可替代的服務時，整個核心邏輯都會隨之更改，遷移成本也是巨大的。

 

2.3 失血模型

失血模型是指領域對象里只有get和set方法的POJO，所有業務邏輯都不包含在內而是放在控制層中，該模型對象的缺點就是不夠面向對象，對象只是數據的載體，幾乎只做傳輸介質之用，它是沒有生命、沒有行為的。

與失血模型相對應的就是充血模型，充血模型就是會包含此領域相關的業務邏輯等，同時也可以包含持久化操作，它的優點對象自洽程度很高，表達能力很強，可復用性很高，更加符合面向對象的思想。

對於創單流程中的對象幾乎都是使用的失血模型，雖然可以完成功能的實現，但是在系統逐漸迭代，業務邏輯逐漸復雜后，采用失血模型會導致業務邏輯。狀態散落在大量的方法中，使得代碼的意圖漸漸不夠明確，代碼的復用性下降。

 

三、DDD設計

通過上文的背景介紹，我們基於DDD思想對攜程國際火車票中台預訂系統做出了一定的重構，使系統實現高內聚、低耦合。

 

3.1 系統設計

Evic Evans將軟件系統的設計分為2個部分：戰略設計和戰術設計。戰略設計提出了域、子域、限界上下文等概念，主要用於指導我們如何拆分一個復雜的系統，戰術設計提出了實體、值對象、聚合、工廠、倉儲。領域事件等概念，主要用於指導我們對於拆分出來的單個域如何進行落地，以及落地過程中需要遵循的原則。

 

3.1.1 戰略設計

 

通用語言

對於國際火車票中台預定系統，我們定義了預定的通用語言：

• 通過用戶搜索條件調用供應商下單；
• 記錄供應商相關數據用於財務統計；
• 根據用戶選定幣種做匯率轉換；
• 根據用戶選擇購買保險；

 

領域

在通過軟件實現一個業務系統時，建立一個領域模型是非常重要和必要的。因為領域模型是整個軟件的核心，其是對某個邊界的領域的一個抽象，反映了領域內用戶業務需求的本質，開發者便可以僅關注領域邊界內所需關注的部分。同時領域對象與技術實現無關，僅反映業務，領域模型貫穿軟件分析、設計，以及開發的整個過程。領域專家、設計人員、開發人員通過領域模型進行交流，彼此共享知識與信息。因為大家面向的都是同一個模型，所以可以防止需求走樣，可以讓軟件設計開發人員做出來的軟件真正滿足需求。

基於此，我們將預定系統划分為了對客訂單和對供應商訂單兩個子域，對客訂單負責處理客戶需要，對供應商訂單負責記錄供應商側的相關數據用於財務統計。

 

限界上下文

划分限界上下文主要是想傳達一種領域設計的思考方式，通過建模來划分清楚業務領域的邊界，划分關系如下所示：

在上圖左側的PS代表合作關系（Partner Ship），右側的ACL表示防腐層（Anticorruption Layer），即右側幾個上下文均是外部領域，需要通過防腐層來轉換交互，以隔離業務。

 

3.1.2 戰術設計

上文提到的失血模型，絕大多數來自於數據庫的Dao對象，因為Dao對象僅僅是數據庫結構的映射，沒有包含業務邏輯，這樣就會導致業務邏輯、校驗邏輯散落在各個service層，不易維護。為了解決這個問題，DDD將領域模型與數據模型做了區分，前者用於內聚自身行為，后者用於業務數據的持久化，倉儲就是用來鏈接這兩層的對象，數據模型又可以分為實體和值對象。

實體

實體（Entity）是指領域中可以由唯一標識進行區分的，且具有生命周期的對象，例如上文中的訂單就是一個實體，其可以通過訂單號進行唯一標識，且訂單在整個預定系統中狀態會發生改變。

 

值對象

值對象（Value Object）是指沒有唯一標識的對象，也就是我們不需要關心對象是哪個，只需要關心對象是什么，例如上文中的行程上下文，故我們不能提供其set方法，行程如果需要改變應該整個對象更新掉。

 

聚合根

聚合（Aggregate）是指通過定義對象之間清晰的所屬關系和邊界來實現領域模型的內聚，並避免了錯綜復雜的難以維護的對象關系網的形成。聚合是一組相關對象的集合，每個聚合有一個根和邊界，聚合根（Aggregate Root）是這個聚合的根節點，其必須是一個實體，邊界定義了聚合內部有哪些實體或值對象。聚合內部的對象可以相互引用，對外通過聚合根進行交互。

 

倉儲

倉儲（repository）就是對領域的存儲和訪問進行統一管理的對象，聚合根被創建出來后進行持久化都需要跟數據庫打交道，這樣我們就需要一個類似數據庫訪問層的東西來管理領域對象。

 

3.2 架構設計

DDD有多種分層架構模式，包括四層架構模式、五層架構模式、六層架構模式等，其核心均是定義一層領域層對領域對象及其關系進行建模，從傳統的MVC三層架構中將領域抽出，但是依然是高層組件依賴低層組件，不同層次之間的耦合無法消除，故本文采用的是一種改進的分層架構模型：六邊形架構，其結構如下所示：

六邊形架構采用依賴倒置原則優化了傳統的分層架構，低層組件應該依賴於高層組件提供的接口，即無論高層還是低層都依賴於抽象，這樣使得整個架構變平。六邊形中每條不同的邊代表了不同類型的端口，端口要么處理輸入，要么處理輸出，這樣就將外界與系統內部進行了隔離，對於每種外部類型，都需要一個適配器與之對應。

六邊形架構的最大特點就是將技術與業務進行分離，六邊形內部核心就是領域模型及不同領域的邏輯編排，領域模型外部的基礎設施層就是為領域模型提供技術實現以及外部系統的適配，因為技術選型在項目之初就已經選定完成並且隨着項目迭代也很少會發生更改，所以業務人員可以將更多的精力放在領域模型的更新上面。

如上文介紹的三方接口結構不穩定情況，也可以通過適配器轉化為內部模型，防止修改成本過高。同時，對於外部請求，無論是通過rpc，REST、HTTP還是通過MQ等方式，均可通過適配器對輸入進行轉化，控制權由此交給內部區域進行處理。同時，上文戰術設計中的倉儲（repository）的實現也可以看作是持久化適配器，該適配器用於訪問先前存儲的聚合實例或者保存新的聚合實例，我們可以通過不同方式實現倉儲適配器，如MySQL、Redis等。

 

四、DDD實現

通過上文分析，本文以國際火車票中台預訂系統項目作為DDD實踐落地。

 

4.1 項目架構

根據DDD六邊形架構原理，系統架構如上圖所示，總共分為了4層：

• gateway：項目入口，其中包括rpc、mq等不同入口；

• infrastructure：基礎設施層，一方面用作防腐，提供不同入口、出口的適配，另一方面實現領域層的接口提供技術實現；

• application：應用層，用於邏輯編排、管理、調度，突出核心邏輯，盡可能輕薄；

• domain：領域層，定義領域模型，對領域模型進行建模；

4.2 領域對象

前文提到DDD要解決的一個重要問題就是對象的失血問題，即對象不能僅作為數據的載體而沒有行為，如上文代碼中的參數校驗應該是其自身的行為而非外部進行校驗，通過適配器轉換為內部對象就可以完成自身參數校驗的行為，代碼如下所示：

public class CreateOrderRequest extends CommonRequest {
    private List<SolutionOfferPair> outSolutionOfferPairList;    private List<SolutionOfferPair> returnSolutionOfferPairList;    private String transactionNo;    ...    private Contact contact;    private List<Passenger> passengerInfoList;    private boolean isSplitOrder;    private boolean randomAssigned;    private List<ExtraInfo> extraInfos;
    @Override    public void requestCheck() {        if (StringUtils.isEmpty(splitPlanId) && CollectionUtil.isEmpty(outSolutionOfferPairList)) {            throw new BusinessException(ResponseCodeEnum.PARAM_ERROR);        }        ...    }}

4.3 戰術設計實現

本文以訂單聚合根為例具體說明戰術設計的實現。

聚合根

聚合根中包含了實體和值對象，同時聚合根與僅有getter、setter的業務對象不同，其將業務邏輯也封裝在內，提高了內聚性，同時將倉儲封裝在內，為聚合根提供持久化操作。

public class P2pOrder {
    private P2pOrderRepository repository;
    @Getter    private long orderId;    @Getter    private OrderMasterModel orderMasterModel;    @Getter    private List<OrderItemModel> orderItemModels;
    public P2pOrder(P2pOrderRepository repository, long orderId) {        this.repository = repository;        this.orderId = orderId;        orderInfoModel = new OrderInfoModel();        orderItemModels = new ArrayList<>();    }        public boolean find() {        return repository.find(this);    }
    public void createOrder(CreateOrderRequest request) {        if (find()) {            throw new BusinessException(ResponseCodeEnum.ORDER_EXISTED);        }        this.orderMasterModel.createOrderMaster(request);        repository.createP2pOrder(this);        // 發送超時支付取消消息        pushDelayMessage(this);    }}

實體

實體是指會存在狀態變更的類，比如order，其可以提供訂單的變更狀態等。

@Getterpublic class OrderMasterModel {
    private OrderStatusEnum orderStatus;    private LocalDateTime ticketTime;    private LocalDateTime expirationTime;    private String lang;    ...
    public void init(CreateOrderRequest request) {        this.channelName = request.getChannelMetaInfo().getChannel();        this.orderStatus = OrderStatusEnum.SEAT_BOOKING;        ...    }
    public void ticketing() {        if (this.orderStatus != OrderStatusEnum.WAIT_FOR_PAY) {            throw new BusinessException(ResponseCodeEnum.ORDER_STATUS_ERROR);        }        this.orderStatus = OrderStatusEnum.TICKETING;    }}

值對象

而值對象是指僅作為描述沒有唯一標識的類，比如行程信息，行程信息變更應該是整個行程信息進行變更而不是提供方法進行修改，故本文針對值對象的構造方法進行私有化處理，並僅提供靜態方法用於重新創建對象。

@Getterpublic class OrderSegmentModel {    private long orderSegmentId;    private short sequence;    private TravelTypeEnum direction;    private String  segmentType;    private String departureLocationCode;    private String departureLocationName;    private String arriveLocationCode;    private String arriveLocationName;    ...            private OrderSegmentModel() {}
    public static OrderSegmentModel init(OrderSegment orderSegment, short sequence) {        OrderSegmentModel model = new OrderSegmentModel();        model.orderSegmentId = Long.valueOf(orderFareId + "0" + orderSegment.getSegmentId());
        model.sequence = sequence;        if (Objects.nonNull(orderSegment.getDepartureLocation())) {            model.departureLocationCode = orderSegment.getDepartureLocation().getLocationCode();            model.departureLocationName = ConvertUtil.getLocationName(orderSegment.getDepartureLocation());        }        if (Objects.nonNull(orderSegment.getArrivalLocation())) {            model.arriveLocationCode = orderSegment.getArrivalLocation().getLocationCode();            model.arriveLocationName = ConvertUtil.getLocationName(orderSegment.getArrivalLocation());        }
        model.departureTime = DateUtil.parseStringToDateTime(orderSegment.getDepartureDateTime(), DateUtil.YYYY_MM_DDHHmm);        model.arriveTime = DateUtil.parseStringToDateTime(orderSegment.getArrivalDateTime(), DateUtil.YYYY_MM_DDHHmm);        ...        return model;    }

 

倉儲

倉儲封裝於聚合根內部，不用於外部調用，故通過工廠方法將倉儲注入聚合根中。

@Slf4j@Componentpublic class OrderFactory {
    @Autowired    private OrderIdGenerator orderIdGenerator;    @Autowired    private P2pOrderRepository repository;
    public P2pOrder create(CreateOrderRequest request) {        long orderId = orderIdGenerator.generateOrderId();        if (orderId < 1) {            log.error("fail to gen order id");            throw new BusinessException(ResponseCodeEnum.FAIL_GEN_ORDER_ID);        }        return new P2pOrder(repository, orderId);    }}

倉儲用於鏈接領域層與數據層，使領域對象與DAO隔離，使我們軟件更加健壯。

@Slf4j@Componentpublic class P2pOrderRepositoryImpl implements P2pOrderRepository {
    @Autowired    private OrderMapper orderMapper;
    @Override    public boolean createP2pOrder(P2pOrder p2pOrder) {        OrderMasterEntity orderMasterEntity = new OrderMasterEntity;        orderMasterEntity.setOrderId(p2pOrder.getOrderId());         orderMasterEntity.setOrderStatus( p2pOrder.getOrderMasterModel().getOrderStatus().getCode());        ...        return orderMapper.insert(orderMasterEntity) > 0;    }}

防腐層

防腐層，又稱為適配層，在對外部上下文的訪問中，就需要引入防腐層對外部上下文進行一次轉義，這樣就可以將外部上下文轉化為內部模型，防止因為外部更改導致改動影響過大。倉儲也是防腐層的一種，因為其隔離了數據庫的DAO對象，轉化為了內部的實體和值對象。在本系統中，也需要對外部的匯率服務、保險服務等引入防腐層的概念。

 

4.4 服務結構

通過DDD思想進行建模，並采用DDD的六邊形架構，重構后的服務結構如下：

 

 

五、總結

本文基於攜程國際火車票出票系統對領域驅動設計進行實踐，通過對出票系統中多個領域的划分使業務邏輯更加清晰，使得代碼易於維護和迭代；並通過領域驅動設計的六邊形架構將業務與技術進行了隔離，突出業務重點，使代碼易於閱讀；加入防腐層使外部上下文與內部模型進行隔離，防止外部對象侵蝕；將迭代需求轉化為各個領域模型的更新，以領域來驅動后續功能開發，使其變得可控，避免了軟件架構設計模式變成“大泥球”模式。

鑒於作者經驗有限，對領域驅動的理解難免會有不足之處，歡迎大家共同探討，共同提高。

參考文獻

[1] Scott Millett 等著, 蒲成 譯; 領域驅動設計模式、原理與實踐(Patterns, Principles, and Practices of Domain-Driven Design); 清華大學出版社, 2016

[2] Evic Evans 著, 趙俐 等譯; 領域驅動設計:軟件核心復雜性應對之道; 人民郵電出版社, 2010

[3] 領域驅動設計在互聯網業務開發中的實踐

[4] 阿里技術專家詳解DDD系列 第二講 - 應用架構

[5] 基於 DDD 思想的酒店報價重構實踐

[6] DDD（領域驅動設計）總結

[7] 談談MVC模式

[8] 阿里技術專家詳解DDD系列 第三講 - Repository模式

[9] 領域驅動設計詳解：是什么、為什么、怎么做？

[10] 領域建模在有贊客戶領域的實踐

[11] DDD分層架構的三種模式