電票是17年上線的一個項目，主要功能比較簡單，由兩個主要部分組成，一個是電票的支付單，一個是電票，功能列表如下。
開發過程
數據表
項目按照以往的經驗，先設計需要的表結構，其中包括支付單關聯以及電票、電票請求三張表（參考了之前類似項目的經驗），並在線下庫新建了表以及表的DO模型、DAO操作等，並根據分工每人負責一個模塊的開發（一共有三人小團隊），直到將近兩兩聯調時突然發現少了部分數據，由於關聯表的操作，模型等都已經實現了，如果在這個表中修改，項目的時間肯定來不及，這個時候只好新增了一張表，然後再跟關聯表通過數據關聯起來，將本來只需要一張表完成的功能拆成了兩張，大大的增加了系統的複雜度。
業務邏輯
業務邏輯採用的是事務腳本的方式，一個電票的管理類將近1600行，所有的邏輯都是按照業務規則平鋪，例如當處理來票時，會先生成一個票據DO，然後嘗試插入數據庫，插入成功之後會發送消息；關聯票據也類似，校驗一系列業務規則之後更新數據庫併發消息。
在第一期項目中這些邏輯也還好，並不算特別複雜，但是隨着需求的不斷新增，例如加入商票的邏輯，加入了系統自動覈銷的邏輯，加入部門隔離的邏輯；電票管理類的職責也越來越多，需求的響應也變的越來越慢。
回顧
如果說從新來一次的話，有哪些可以改進的地方呢？
首先說數據表遺漏的問題，最近參加了一個培訓，裏面有一課講的比較好，說的是自頂向下，意圖編程，測試先行，與TDD類似。自頂向下是指從上層的語義開始而不是從數據表開始，因爲上層的語義更加具有確定性，因此出錯的機率更低，在真正需要的時候再來設計數據結構與表結構。再多說一次TDD，工作的這些年中發現沒有一個團隊在實行TDD的，可能是系統本身複雜度不夠高，認爲TDD開發效率不高，也可能是沒有這方面的意識等。不過從我之前實踐過的一個項目來看，效果還是不錯的，一方面可以保證系統質量，更重要的是可以強制去更多的思考系統的結構，例如需要去進行接口的mock，這樣設計出來的系統天然就具有更好的擴展性。
其次如何面對業務的變化，隨着業務規則的不斷變更，對系統之前的一些邏輯帶來了挑戰。在一些實踐場景下可能就通過ifelse來疊加上去，導致系統越來越複雜。最近參加的培訓中也談到了這個問題，再加上之前內網中的文章結合來看，可以開始把應用層做厚，領域模型做薄，然後隨着編碼的深入，將確定性的邏輯移到領域中；當新規則打破之前的領域邏輯時，再進行重構去適應。
其他
回顧中的一些想法還並沒有去實踐，還需要一些項目去證實或證僞。