這篇來聊聊我參與支付系統的設計經驗，也反思，如果在未來如果還有機會，我應該要做什麼準備？會怎麼做？下面所提到的系統，已經停用被其他新系統所取代，我將不會把系統的細節與專有名詞直接暴露，避免爭議。
前情提要
過去曾經以乙方的身份，參與多項系統開發與維運，其中包括電子採購系統、CRM、eCommerce與支付系統。每個系統都讓我有許多不同的收穫，其中支付系統是一個龐大、複雜且營運時間超過十二年的系統。支付系統開發廠商也就是我的前雇主，在系統上線後留下團隊，持續協助甲方後續的維運與系統增修工作；我是在系統上線八年後，才參與兩年多的系統分析與設計工作。系統開發初期是由上百位Developer參與，在系統完成後，僅留下五位Developer與三位分析師持續接受客戶需求變更。團隊中的五位Developer對整個系統的掌握度極高，流動的分析師們相當依賴他們，畢竟沒有任何一位分析師待得比他們久。多年來，需求變更不斷，使用情境越來越複雜，所以沒有太多時間可以重新思考架構。
機會的起點
為了需求變更，我們需要常常與Developer請教原系統架構設計，並討論如何將客戶需求加到系統裡；除了資料庫的設計混亂與誤用，程式碼部分，我發現，為了做交易檢核與多種不同交易情境分流，程式碼裡面散落了數不清的if-else 判斷式，可讀性不高；每次調整需求，就要在合適的地方加入新的檢核或是交易條件；而每次進行這樣的調整，就需要冒著破壞原有程式碼的風險。因此，我在一次增加交易模式的機會，與當時負責的Developer討論加入一些 Patterns的可能。Richard是當時與我一同負責那次需求變更的Developer，我跟他提起我的構想，幾次討論之後，他興致勃勃的開始進行新架構的嘗試，如果沒有他的幫忙，我們應該很難驗證我們的想法是否可行。
系統概觀
此系統提供客戶線上交易服務，而後端則有許多不同的協力廠商，可銷售多樣性的商品，但因為歷史因素，有兩群不同時期招募進來的廠商，使用結構完全不同的資料庫，更遑論後期的Google Play Store等新型態的交易。把遙控器改造成一把瑞士刀，是很多系統的發展過程，這個支付系統也不例外。
簡單來說，系統的狀況如下：
- 前端有許多不同型態的使用者。
- 後端有許多不同類型的商家。
- 商品可以是一次性付款購買，也可以是月租式訂閱。
- 付款方式可以是月節帳單，也可以是信用卡交易。
- 所幸，每種交易類型都有著一樣的步驟。
不難想像，這些情境的排列組合之後，交易與檢核會有多少判斷工作需要做。第一步，我們針對每種交易流程做了分析，每種交易流程有一定的步驟，所以我們想要採用State Pattern配合 Factory Pattern，在每個交易請求進到系統的時候，經由判斷選用某一個設計好的交易流程，而這個流程則是由Factory Pattern組裝好的 State Pattern，藉此將混在一起的交易流程分開來。未來的擴充，也僅需要在Factory Pattern前端，設定一個新的交易流程判斷，並於加入一組新的State Pattern，即可完成新交易的設定，而不會更動到原有的交易，滿足了封閉-開放原則；當然，這次僅能針對新增加的交易類型，部分嘗試這個構想。
我們第二步想解決許多不容易判讀的if-else；我們將判斷式封裝起來，也給予具有意義的名稱，再運用 Java 的 Reflection 機制，將每一個判斷式的class 名稱儲存在資料庫裡，這樣做的好處是可以在資料庫裡調整檢核順序，也更容易且安全的調整檢核條件。我們只要將資料庫的檢核資料表撈出來，運用Reflection，把class還原回去(這個過程有點像是把冷凍蔬菜加熱水，看起來又跟新鮮蔬菜一樣神奇，XD)，之後再把需要檢核的資料塞進去，取得回傳的布林值，就可以取代原來一整串的 if-else。即便未來需要增加檢核條件，我們僅需要實作一個 Condition，再到資料庫設定一筆檢核資料，就可以輕鬆擴充，形成一個小小的規則引擎。
當時很順利的完成新交易的設計，也為系統以後的發展奠定基礎，最開心的是聽到Richard感慨地說：這麼多年來，這個系統終於有點物件導向的感覺。但是可惜的是甲乙雙方因為預算與時程的關係，遲遲未能將這個設計延續下去，徹頭徹底的改造整個系統；而我又想挑戰自己，跳入另外一個困難的專案中XD。如果還有機會，不論再用一次OOAD或是改用DDD分析、設計系統，我想重新建模，採用更多的設計模式，並擺脫原來舊有且疊床架屋的資料庫結構，應該可以讓這個系統的發展更加健康。
