機票業務非常複雜，我們不得不應對這些複雜，也不斷的想出一些招數演進系統。我回顧所做的事，再次思考并歸納核心思路，完成了本篇。
一、最大化統一，最小化變化
業務複雜，更不能随意新增接口、流程，思考如何将不同場景的流程融合在一起。
圖例：逐級搜尋機票展示結果
航班頁、低價頁、填寫頁沒人會拆成三個流程分别實作，盡可能提取出不變的部分，将變化降到最低。低價頁支援填充坑位的需求之前，排序層統一做合并；之後，排序層統一做坑位填充。
配圖：低價頁需要支援填充坑位，那航班頁也采用填充方式
流程所經過的分層、步驟是統一的，一些細節的操作是變化的。
| 航班頁 | 低價頁 | 填寫頁 | |
| 過濾條件 | 出發、到達、出發日期 | +航班号 | +代理商、艙位、産品 |
| 産品計算層 | 最低價産品 | 排序層需要展示的産品 | 選中的産品 |
| 排序層-填充階段 | 每個航班選最低價 | 對每個坑位按指定優先級填充産品 | - |
| 排序層-排序階段 | 價格由低到高 | 定義的坑位順序 | |
| 校驗層 | 與資料庫校驗 |
表格：每一層變化的部分
二、标準化，子產品化，配置化
随着不斷新增的業務場景，被動引入各種類型的變化，流程越改越亂，配置糾纏不清。直到有一天老闆也看不下去了：“你們隻會加那不叫本事，敢于删才叫本事”。但要怎麼删呢？
配圖：各種if、else，各種配置，亂作一團
不同來源對應不同變化，将散亂的來源标準化，用以規範變化的引入。
将同類變化提煉到一起，固化成業務上内聚的子產品。
将提練後剩下的真正變化采用配置的形式。
配圖：變化來源的三大類别，管道、人群、搜尋模式；變化行為屬于平台控制的各個業務子產品
管道的定義“端、容器、入口”并不是包含關系，而是組合。像改簽搜尋、機票寶貝搜尋相關的一類需求，我們稱作入口。
這樣一來，航司限價的代碼是通用的，變化的隻是對“API-MTOP-外采”設定所有航司不限，對“無線-APP-小搜”配置限價航司。流程是通用的，變化被配置化。
三、産品化
航司限價有了針對不同管道、人群的配置，配置是否對業務方足夠透明，使其完全了解業務含義，并獨立修改呢？由研發人員修改的配置隻是另外形式的代碼，被業務方使用的配置才是可控的産品。
曾經排查線上特定商品不展示問題，有段業務邏輯把該商品幹掉了，營運根本不知道有這個功能，隻有代碼自己知道。
不斷疊代的需求，不斷引入的變化，缺少輸出、無法控制，代碼靜靜的躺在那裡，有多可怕。
前面提到的都是引入變化的技巧。複雜的業務往往對應更多的子產品、分層、系統，後面談談邊界及互動的思路。
四、明晰邊界
做劃分通常會遵從高内聚、低耦合的标準，實際操作時往往沒那麼簡單，時不時會遇到些模棱兩可的情況。
1、改簽流程中，交易與搜尋系統的邊界
計算改簽費用放在哪做成為争論的焦點。隻傳回将改簽到的商品的官方指導價，還是算出改簽客戶要付的費用來？最終結論是計算改簽費用放在交易。因為搜尋系統是無狀态的，而訂單是有狀态的，是以和狀态相關（比如二次改和一次改手續費算法不同）的邏輯放在交易系統更合适。也許這次的需求隻支援一次改，隻是一個固定的手續費，但一定要把潛在引入的變化考慮進去。對于本例，我們找出了兩個系統不同的本質特性“狀态”，進而判斷出功能适合内聚到哪。
配圖：搜尋要支援改簽按航司規定的過濾（藍色），該不該支援改簽費用計算（綠色）？
2、特殊優惠展示成劃價，放在搜尋還是營銷系統？
營銷已經實作了用劃價展示已減優惠（營銷系統知道）；新增的特殊優惠（搜尋系統知道、營銷系統不知道）希望展示成劃價的形式。如果隻考慮工作量，讓營銷系統把特殊優惠也作為一種優惠來處理，複用劃價展示的邏輯。另外的做法是搜尋也支援劃價展示，相當于展示層需要感覺搜尋、營銷兩者的劃價展示。是否放到營銷的關鍵點是确定系統邊界，是不是以後所有的減價形式都算營銷？
配圖：最終采用的方案，搜尋告訴營銷系統動态新增特殊優惠的活動（綠色）
直到項目做完我心裡也沒有定論，用的是不是最合理的方案。似乎放在搜尋合理一些，但如果僅僅為支援這一個業務場景去改動，考慮的還不夠全面。
五、統一互動
互動時始終使用同一種語言才友善，機票搜尋本質是商品的搜尋，需要統一的商品模型，我們實際做的還不夠。
1、搜尋系統在填單頁把商品快照給交易系統，商品模型不夠完善，不包含“是否驗價”、“驗價的office号”、“是否自動占座”等資訊，交易系統需要自己判斷從哪個基礎資料上擷取相應資訊。
配圖：商品快照，一半是商品模型，一半是資料庫對象
2、國内與國際搜尋商品模型不統一，造成營銷需要分别為國際國内提供二方包。
配圖：營銷分别提供國内、國際工具，來比對不同格式的機票商品
試想如果有統一的機票商品模型，這些流程會友善很多，國内與國際的聯程拼接實作起來也會簡單許多。