12306核心模型設計思路和架構設計

12306核心模型設計思路和架構設計

技術人員每每更注重技術層面的解決方案，好比一上來就分析如何集羣、負載均衡、排隊、分庫分表、用鎖，用緩存等技術問題，而忽略了最根本的業務層面的思考，如分析業務、領域建模。其實複雜的業務系統，則越要設計一個健壯的領域模型。若是一個系統的架構咱們設計錯了，還有補救的餘地，由於架構最終沉澱的只是代碼，調整架構便可；而若是領域模型設計錯了，那要補救的代價是很是大的，由於領域模型沉澱的是數據結構及其對應的大量數據，對任何一個大型系統，要改核心領域模型都是成本很是高的。

12306這個系統，核心要解決的問題是網上售票。涉及到2個角色使用該系統：用戶、鐵道部。用戶的核心訴求是查詢餘票、購票；鐵道部的核心訴求是售票。購票和售票實際上是一個場景，對用戶來講是購票，對鐵道部來講是售票。所以，咱們要設計一個在線的網站系統，解決用戶的查詢餘票、購票，以及鐵道部的售票這3個核心訴求。看起來，這3個場景都是圍繞火車票展開的。最主要的需求就是查詢餘票和購票。

其實能夠將12306類比成一個商品是車票的電商系統，那購票就相似於購買商品，而後每張票都有庫存，商品也有庫存的概念。可是若是咱們仔細想一想，會發現12306要複雜不少，由於咱們沒法預先肯定好全部的票，若是非要肯定，那隻能經過窮舉法了，實際上，這個車次能夠賣的票是很是多的。爲了方便後面的討論，咱們先明確一下票是什麼？經過分析，咱們能夠知道一張票的本質是某個車次的某一段區間（一條線段），這個區間包含了若干個站點。而後咱們還發現，只要區間不重疊，那座位就不會發生競爭，能夠被回收利用，也就是說，能夠同時預先出售。另外，通過更深刻的分析，咱們還發現區間有4種關係；不重疊部分重疊、徹底重疊、覆蓋，不重疊的狀況咱們已經討論過了，而覆蓋也是重疊的一種。因此咱們發現若是重疊，好比有兩個區間發生重疊，那重疊部分的區間（可能誇一個或多個站點）是在爭搶座位的。由於假設一列火車有100個座位，那每一個原子區間（兩個相鄰站點的連線），最多容許重疊99次。一個車次可以出售一張車票的核心業務規則是這張車票所包含的每一個原子區間的重疊次數加1都不能超過車次的總座位數，實際上重疊次數+1也能夠理解爲線段的厚度。

GRASP九大模式中的信息專家模式，將職責分配給擁有執行該職責所需信息的類。咱們這個場景，車次具備一次出票的全部信息，因此咱們應該把出票的職責交給車次。DDD中聚合設計有一個原則，就是：聚合內強一致性，聚合之間最終一致性。票不是核心聚合根，票只是一個計算的結果，一個憑證而已，票自己沒有什麼邏輯；12306真正的核心模型應該是車次，車次具備出票的職責，並以強一致性的方式維護一次出票（或退票）時全部原子區間的可用票數。2306這樣的業務場景，很是適合使用CQRS架構；由於首先它是一個查多寫少、可是寫的業務邏輯很是複雜的系統。因此，很是適合作架構層面的讀寫分離，即採用CQRS架構