Hero Image
需求設計與反省

需求設計與反省 最近面試遇到些需要我描述 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)

Hero Image
分散式系統

Distributed System 分散式系統設計,Net 8 服務,啟用 nginx upstream 從單機到多實例後,遇到的設計問題。 核心概念:Stateless Service 什麼是 Stateless? 定義:服務的每個實例不保留任何與特定請求或使用者相關的狀態資訊。 為什麼需要 Stateless? ┌─────────┐ ┌──────────────┐ ┌──────────┐ │ Client │────▶│ Load Balancer│────▶│Instance A│ └─────────┘ └──────────────┘ ├──────────┤ │ │Instance B│ │ ├──────────┤ └─────────────▶ │Instance C│ └──────────┘ 當你的系統從 1 台機器擴展到 N 台時: 請求分散:用戶的連續請求可能落在不同實例 實例隨時變動:Auto-scaling 會新增/移除實例 故障轉移:某個實例掛掉,流量會轉到其他實例 ❌ 禁止使用的狀態儲存方式 方式 為什麼不行 實際案例 IMemoryCache 只存在單一實例 User A 的資料在 Instance A,但下次請求到 Instance B static 變數 無法跨實例共享 計數器在每個實例都是獨立的 Singleton 內部狀態 每個實例有自己的 Singleton Session 資料只存在啟動該請求的實例 檔案系統 本地儲存 上傳的檔案只在一台機器上 ✅ 狀態必須外部化 所有狀態都必須存放在所有實例都能存取的外部系統:

Hero Image
多租戶 JWT 驗證架構

LineCRM.CarCare 登入架構說明 Multi-Tenant JWT Authentication 多租戶(Multi-Tenant)JWT 雙 Token 認證機制(Access Token + Refresh Token),支援商店用戶(Store)與客戶用戶(Customer)兩種身份類型的獨立認證流程。透過泛型設計與介面抽象,實現了可擴展的多角色登入系統,並結合 Redis 快取機制管理 Refresh Token,提供安全且高效的身份驗證解決方案。 Key Features 雙 Token 機制:Access Token (短效) + Refresh Token (長效) 多角色支援:Store User 與 Customer User 獨立認證 自動 Token 更新:Middleware 自動偵測過期並刷新 分散式快取:Redis 管理 Refresh Token 狀態 安全性強化:HttpOnly Cookie + CSRF 防護 可擴展架構:新增用戶類型僅需實作兩個介面 1. Adapter Pattern (適配器模式) 位置: StoreInfo 、 CustomerInfo、 IClaimAdapter.cs public interface IClaimAdapter<CurrentUser> { IEnumerable<Claim> GetClaims(); static abstract CurrentUser? FromClaimsPrincipal(ClaimsPrincipal principal); } public class CustomerContext : AppDataContext<CustomerInfo> { public CustomerContext(IHttpContextAccessor httpContextAccessor, IBaseLogger log) : base(httpContextAccessor, log) { } public override CustomerInfo? CurrentUser { get { var user = _httpContextAccessor.HttpContext?.User; return CustomerInfo.FromClaimsPrincipal(user); } } } public class CustomerInfo : IClaimAdapter<CustomerInfo> { public IEnumerable<Claim> GetClaims(){} public static CustomerInfo? FromClaimsPrincipal(ClaimsPrincipal principal){} } 說明: