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

一、前言

領域驅動設計（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分層架構的三種模式

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/302948.html

標籤：領域驅動設計

上一篇：服務治理在資源中心的實踐

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