需求設計與反省

最近面試遇到些需要我描述 SA 或是 SD 的工作經驗描述，發現我講得的零零落落的，不然就是根本忘了，故挑幾點印象比較深刻做文字整理，以便以後需要的時候可以回來這裡回想。

郵局信箱與招領

所有信箱都來自實際存在的地址，在第一次申請(141)建立可投遞的信箱維護所有基本資料(姓名、電話等等…)依賴信箱主檔與客戶基本檔。

實際投遞遇到問題或是租戶自行申請將影響信箱狀態變更(142 狀態如:續租或暫停使用等等…)，影響信箱生命存續終止(145、146 如退租、屆期未續、轉空戶)。

若通訊地址有更改請先執行維護信箱交易(154 調整為改投或i郵箱)再執行退租，此時的通訊地址才會正確。

由多個交易可以看出信箱的所有狀態與存續的的生命週期。

所有變更資料面依賴信箱主檔、變更歷程寫入 BoxChange_LG(變更歷程)且幾乎所有報表查詢都會依賴變更歷程的最新一筆。

大量的計算邏輯(報表 781、782…)有大量的 sql 重複查詢，其實就是不同的查詢條件，可以彙總成共用 lib 抽離不同件數計算邏輯，不需要每個欄位都一個複雜又重工的 sql 指令。

反省:

礙於專案時程壓力，只好先寫寫看在再回過頭看需求細節的真實用意，其實很危險，很多姑且先寫寫看的功能，都會在終於懂得哪一刻發現很多多此一舉的地方，甚至在 QA 深入各個交易互測階段發現一些明顯邏輯不通的錯誤。

如果可以先了解欄位/物件真義，再進行開發還是比較好，但就是會需要說服 SA 把其他相關的交易規格都拿到，即便是大致掃一眼也是好的。

個資軌跡 h 銀行

個資軌跡交易類別，依 dal 實際邏輯做 function 做預設值參考，服務可以傳入參數強制改為要或不要寫入個資軌跡。

trackType比如: 查詢(新增/修改/刪除交易的查詢、新增 、修改 、刪除 等等。

db Entity 新增 annotation 註記不同機敏程度的代號，透過共用的 Repositary 層偵測更新的 model 牽涉機敏欄位多寡來記錄個資軌跡，並抽離以方便維護是否紀錄的邏輯

    if (A_TypeCount >= 2 || (A_TypeCount >= 1 && B_TypeCount >= 1))
        return 則記錄個資軌跡;

反省:

資料面攔截所有系統的機敏軌跡，但忽略列的業務邏輯層建立的 dto 也有個資，dal 可以寫入的內容有限，只能記錄自定義的 trackType 且依賴回傳的 TEntity result，如果回傳結果有多層 entities 結構，無法紀錄深層機敏資料( 多層 Entity 結構 )且會顯示 Expression Tree (LINQ 原始表達式字串) 無法讀取內容物例如: c.IdNo == value(HuaNan.Service+<>c__DisplayClass3_0).input.IdNo)

代收付

代收付的本質是替第三方背書這筆資金移轉的正當性。

所以有幾個重點要注意，可控、可對帳、可回溯。

分錄服務，把代收付轉成借貸分錄，把所有交易都記錄起來，變成會計事實

核可服務，對帳戶的檢核、餘額的檢核等等

實際交易服務，主機回傳結果檔作為法律與主機認可的證據，是這筆代收付「真的入帳」的唯一依據。

所以不管是核心主機作所有事，還是已經析離過建立外部系統，都會有這些核心功能，還沒析離前也會是核心主機獨立的 Module，析離過的就會是獨立的 api，看銀行架構，有可能會有中間的 EBS 或 gateway 去接資料

這三個服務分別對應可控、可對帳、可回溯必須完全解耦，不可互相依賴或混合使用。

他們都會共用 spec 來源稱為交易表、以及借貸分錄需要入扣帳表，在分類上需要做的很彈性讓這些服務都可以支援分辨得出扣款內容，比如系統上的台電費用 Taipower 但走臨櫃繳費的代號是 008 走行內入扣代號可能是 TPC，這些明確關聯的的類別需要 scan 所有需求拉出大項，維護關聯小項，已避免進入開發的時候類別靜態維護，或是 SD 階段設計使用感覺像 Enum 但是可繼承的類別(內容使用 static string type)

再來視專案規模，會有擴展更多來源( 稱之為不同的通路 )要分階段開發與交付，比如臨櫃代收、虛擬帳戶代收( FICS/ACH )、超商代繳、DXC( 信用卡主機 )等…就會需要額外介接外部 api 且整合測試的範圍更大。

反省:

過度設計的通用業務類別、通路類別可能不必要，每家銀行的代收付核心流程差異過大，且合作營業部門的分類的方式也可能不同，硬要提取共用業務類別、共用通路來適合所有銀行，建立一個穩定可擴充的的代收付產品，可能性不高，最終將囿於過多的例外設計導致底層工廠通用性不佳。

可繼承的 Enum static string type 預期效果是程式維護類別，業務類別更動機率不大，但影響的層面是 db 資料面為彈性維護缺發關聯，不易辨識類別意義，在上線問題排查的過程難以一眼看出問題。

信用額度

信用卡調整額度轉介單，面向個人需要徵詢個金，企業用戶則需要徵詢法金不同的外部 api，徵詢依賴人工審件，所以所有申請轉介單都會有狀態管理，搭配批次服務定期抓檔 ftp 匯入外部審核結果整批更新轉介申請單申請。

且所有變更紀錄均要寫入歷程記錄，方便櫃員參考，比如 x 年調高 n 萬，目的是信用卡繳交房屋稅，今年同一時間也一樣目的，額度不同就需要櫃員追問原因

並產出報表功能，匯出特定時間用戶與額度調整結果。

需求訪談深入了解每個欄位型別、下拉細項，與外部溝通 Api 對應欄位以及格式化需求。

汽修服務

店家 Store，為 CRM 平台 end user，即汽修業者。

顧客 Customer，為 Store 預約平台 end user 即一般車主。

登入共用 Line OA 與 server jwt stateless 驗證，區分不同 context 取當前 user

Store 只關注"汽車"本身，所以客戶列表主體為 StoreCustomerCar (具 store、customer 的 car 主體)

Customer 則關注 Customer 本身，且產業競爭意識，Customer 登入必須完全在 特定店家的資料之下顯示(不可看到其他店家)

反省:

導入油品經銷的過程，的確把推銷壓力轉移到經銷商身上，但同時為了符合經銷商要求，產品加入太多經銷要求的例外邏輯，產品逐漸專案化

ToB 與 ToC 的搖擺不定，期望先主要 ToB 待使用者規模逐漸增加，再改產品策略導向 ToC，但卻囿於 ToB 本質的產業競爭意識導致產品 ToC 的可能性逐漸微弱，因架構上 Store 的依賴與其他店家資料不可見(身為平台車主客戶，登入過一次資料，再去其他合作店家，卻要重新再輸入)。