務(wù)邏輯到代碼實現(xiàn)：抽象思維的四個層次與實踐技巧)
1. 老代碼引發(fā)的思考為什么我們需要重新審視開發(fā)思路那天整理舊項目時我翻出了五年前寫的一段業(yè)務(wù)邏輯代碼。當(dāng)時為了趕進(jìn)度我直接按照產(chǎn)品文檔的要求把每個功能點都實現(xiàn)了出來?，F(xiàn)在回頭看那些代碼就像是用膠帶粘起來的積木——雖然能用但牽一發(fā)而動全身。最典型的是一個訂單狀態(tài)流轉(zhuǎn)的功能我寫了將近800行的if-else嵌套現(xiàn)在要加個新狀態(tài)得把整個文件重寫一遍。這讓我意識到很多開發(fā)者包括當(dāng)年的我常犯的一個錯誤拿到需求就急著寫具體實現(xiàn)。我們太關(guān)注怎么做而忽略了更重要的為什么要這樣做。就像建房子先打地基一樣寫代碼前應(yīng)該先理清業(yè)務(wù)邏輯的本質(zhì)。提示下次接到新需求時試著先問三個問題這個功能的核心目標(biāo)是什么它與現(xiàn)有系統(tǒng)的關(guān)系如何未來可能有哪些變化2. 抽象思維的四個層次從業(yè)務(wù)到代碼的完整路徑2.1 第一層業(yè)務(wù)概念抽象最近接手的一個電商優(yōu)惠券系統(tǒng)就是個好例子。產(chǎn)品經(jīng)理最初的需求文檔里提到了滿減券、折扣券、贈品券等十幾種類型。如果直接照搬這些具體類型去建模代碼很快就會變得難以維護(hù)。我的做法是找出所有券類型的共性都有有效期、使用條件、優(yōu)惠效果識別變化點條件判斷邏輯如滿X元和優(yōu)惠計算方式如減Y元建立核心抽象Coupon券基類、Condition條件接口、DiscountStrategy優(yōu)惠策略接口interface ICondition { isSatisfied(order: Order): boolean; } interface IDiscountStrategy { applyDiscount(order: Order): void; } abstract class Coupon { constructor( public conditions: ICondition[], public strategy: IDiscountStrategy ) {} validate(order: Order) { return this.conditions.every(cond cond.isSatisfied(order)); } apply(order: Order) { if (this.validate(order)) { this.strategy.applyDiscount(order); } } }2.2 第二層流程控制抽象在開發(fā)一個文件導(dǎo)入功能時我發(fā)現(xiàn)雖然文件格式CSV/Excel/JSON不同但處理流程高度一致驗證→解析→轉(zhuǎn)換→存儲。于是設(shè)計了這樣的流程控制器abstract class FileProcessor { async process(file: File) { await this.validate(file); const data await this.parse(file); const entities this.transform(data); return this.save(entities); } abstract validate(file: File): Promisevoid; abstract parse(file: File): PromiseRawData; abstract transform(data: RawData): Entity[]; abstract save(entities: Entity[]): Promisevoid; }這樣新增格式時只需繼承這個基類實現(xiàn)四個方法無需改動現(xiàn)有流程代碼。2.3 第三層設(shè)計模式的應(yīng)用在消息通知系統(tǒng)中我最初為每種通知類型郵件、短信、站內(nèi)信寫了獨立的方法。當(dāng)需要支持新渠道如企業(yè)微信時發(fā)現(xiàn)要修改多處發(fā)送邏輯。用策略模式重構(gòu)后interface NotificationStrategy { send(user: User, message: string): Promisevoid; } class NotificationService { private strategies new Mapstring, NotificationStrategy(); register(type: string, strategy: NotificationStrategy) { this.strategies.set(type, strategy); } async notify(user: User, type: string, message: string) { const strategy this.strategies.get(type); if (!strategy) throw new Error(Unsupported type: ${type}); return strategy.send(user, message); } } // 使用 service.register(email, new EmailStrategy()); service.register(sms, new SMSStrategy()); // 新增渠道只需添加實現(xiàn)類并注冊2.4 第四層領(lǐng)域驅(qū)動設(shè)計實踐在供應(yīng)鏈系統(tǒng)中我嘗試用DDD劃分邊界。比如將庫存這個概念從簡單的數(shù)據(jù)庫表升級為獨立的領(lǐng)域模型class Inventory { private items: Mapstring, InventoryItem new Map(); constructor(private repository: InventoryRepository) {} async load(sku: string) { this.items.set(sku, await this.repository.findBySku(sku)); } allocate(order: Order): AllocationResult { // 復(fù)雜的庫存分配邏輯 // 包含業(yè)務(wù)規(guī)則先進(jìn)先出、批次追蹤等 } getStockLevel(sku: string): number { return this.items.get(sku)?.quantity || 0; } }這樣將業(yè)務(wù)規(guī)則封裝在領(lǐng)域?qū)ο髢?nèi)避免業(yè)務(wù)邏輯泄漏到應(yīng)用層。3. 從抽象到實現(xiàn)的五個實操技巧3.1 白板設(shè)計法我團(tuán)隊現(xiàn)在有個規(guī)矩任何新功能開發(fā)前必須先在白板上畫清楚核心實體及其關(guān)系關(guān)鍵業(yè)務(wù)流程可能的變化點最近設(shè)計支付系統(tǒng)時我們花了整整兩天在白板前討論最終確定了這樣的架構(gòu)[支付網(wǎng)關(guān)] ←→ [支付處理器] ←→ [交易核心] ↑ ↑ [風(fēng)控系統(tǒng)] [會計系統(tǒng)]這個過程中發(fā)現(xiàn)了三個重要問題退款流程需要特殊風(fēng)控規(guī)則跨境支付涉及多幣種會計處理需要支持異步通知重試機(jī)制提前發(fā)現(xiàn)這些問題節(jié)省了至少兩周的返工時間。3.2 契約先行開發(fā)在微服務(wù)項目中我習(xí)慣先用OpenAPI定義接口契約paths: /orders: post: requestBody: content: application/json: schema: $ref: #/components/schemas/OrderRequest responses: 201: description: Created content: application/json: schema: $ref: #/components/schemas/OrderResponse components: schemas: OrderRequest: type: object properties: items: type: array items: $ref: #/components/schemas/OrderItem # 其他定義...這樣做的好處前端可以并行開發(fā)mock數(shù)據(jù)明確接口邊界避免后期扯皮自動生成類型定義和文檔3.3 測試驅(qū)動抽象寫測試能倒逼出好的抽象。比如最近開發(fā)配置管理系統(tǒng)時我這樣開始describe(FeatureToggle, () { it(should return false for undefined feature, () { const toggle new FeatureToggle({}); expect(toggle.isEnabled(new-ui)).toBe(false); }); it(should respect environment-specific override, () { const toggle new FeatureToggle({ new-ui: { default: false, staging: true } }); expect(toggle.isEnabled(new-ui, staging)).toBe(true); }); });這個測試促使我設(shè)計出這樣的實現(xiàn)class FeatureToggle { constructor(private config: FeatureConfig) {} isEnabled(feature: string, env: string default): boolean { const featureConfig this.config[feature]; if (!featureConfig) return false; return featureConfig[env] ?? featureConfig.default ?? false; } }3.4 可視化建模工具復(fù)雜業(yè)務(wù)系統(tǒng)建議使用PlantUML等工具建模。這是我們最近物流系統(tǒng)的狀態(tài)圖示例startuml state 待攬收 as pending state 運輸中 as shipping state 已簽收 as delivered state 異常 as exception [*] -- pending pending -- shipping: 攬收成功 shipping -- delivered: 客戶簽收 shipping -- exception: 運輸異常 exception -- shipping: 問題解決 enduml這種可視化表達(dá)幫助團(tuán)隊達(dá)成共識也更容易發(fā)現(xiàn)狀態(tài)機(jī)設(shè)計缺陷。3.5 重構(gòu)雷達(dá)機(jī)制我們建立了代碼壞味道雷達(dá)圖定期評估重復(fù)代碼率方法復(fù)雜度類職責(zé)數(shù)量依賴關(guān)系深度當(dāng)某個指標(biāo)超標(biāo)時立即安排重構(gòu)。比如最近發(fā)現(xiàn)訂單處理器類的process方法超過了100行立即拆分為OrderValidatorOrderCalculatorOrderNotifier每個類專注單一職責(zé)代碼可讀性大幅提升。4. 常見陷阱與解決方案4.1 過度抽象問題去年我設(shè)計過一個萬能表單渲染器試圖用一套配置支持所有業(yè)務(wù)表單。結(jié)果配置復(fù)雜度反而超過了直接寫組件{ fields: [ { type: nested, conditions: [ {field: userType, operator: equals, value: vip} ], fields: [ {name: vipCode, component: Input, rules: [required]} ] } ] }教訓(xùn)是抽象應(yīng)該遵循三次法則——當(dāng)?shù)谌斡龅较嗨菩枨髸r再抽象。4.2 領(lǐng)域模型貧血癥早期我常寫出這樣的貧血模型class Order { public items: OrderItem[]; public status: string; // 只有g(shù)etter/setter } class OrderService { calculateTotal(order: Order) { // 計算邏輯放在service里 } }改進(jìn)后的充血模型class Order { private items: OrderItem[]; private status: OrderStatus; get total(): number { return this.items.reduce((sum, item) sum item.price * item.quantity, 0); } markAsPaid() { if (this.status ! pending) { throw new Error(Invalid status transition); } this.status paid; } }4.3 抽象泄漏問題有次設(shè)計緩存層時底層Redis的異常直接拋給了業(yè)務(wù)代碼class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { // Redis連接錯誤直接暴露 throw err; } } }正確的做法是封裝領(lǐng)域異常class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { throw new ProductRepositoryError(Failed to access product, err); } } }4.4 過早優(yōu)化陷阱我曾為了性能設(shè)計過極度抽象的查詢構(gòu)建器const query new QueryBuilder() .select(id, name) .from(Product) .where( new ConditionGroup(AND, [ new Condition(price, , 100), new Condition(stock, , 0) ]) ) .build();后來發(fā)現(xiàn)95%的查詢都很簡單復(fù)雜查詢直接寫SQL更清晰性能瓶頸其實在索引設(shè)計現(xiàn)在遵循YAGNI原則除非確有需要否則保持簡單。5. 個人工具箱分享5.1 抽象思維訓(xùn)練法我每周會做這樣的練習(xí)選一個日常事物如咖啡機(jī)列出其主要功能識別變化點咖啡種類、杯型等設(shè)計抽象接口想象未來可能的擴(kuò)展例如電梯系統(tǒng)的抽象練習(xí)interface ElevatorController { requestFloor(floor: number): void; getCurrentFloor(): number; getDirection(): up | down | idle; } interface SchedulingStrategy { nextFloor(requests: number[], current: number): number; }5.2 代碼評審檢查清單在我的團(tuán)隊PR模板中包含這些抽象相關(guān)檢查項[ ] 是否存在重復(fù)邏輯[ ] 新增代碼是否適合現(xiàn)有抽象[ ] 是否需要創(chuàng)建新的抽象[ ] 領(lǐng)域知識是否泄漏到應(yīng)用層[ ] 接口設(shè)計是否遵循ISP原則5.3 架構(gòu)決策記錄(ADR)我們用markdown記錄重要抽象決策# 2023-05-01 支付網(wǎng)關(guān)抽象方案 ## 狀態(tài) 已采納 ## 背景 現(xiàn)有支付對接方式支付寶、微信支付直接耦合在訂單服務(wù)中 ## 決策 引入支付網(wǎng)關(guān)抽象層┌─────────────┐ ┌──────────────┐ │ 訂單服務(wù) │───────?│ 支付網(wǎng)關(guān) │ └─────────────┘ └──────────────┘ ▲ ┌───────────────┴───────────────┐ │ │ ┌──────────────┐ ┌──────────────┐ │ 支付寶適配器 │ │ 微信支付適配器│ └──────────────┘ └──────────────┘## 影響 - 正面新增支付渠道只需實現(xiàn)適配器 - 負(fù)面增加一次調(diào)用跳轉(zhuǎn)5.4 可視化抽象工具鏈我的常用工具組合Miro用于業(yè)務(wù)流程抽象Draw.io繪制架構(gòu)圖TypeScript Playground快速驗證接口設(shè)計Jest通過測試驅(qū)動抽象Postman模擬接口契約5.5 持續(xù)學(xué)習(xí)資源推薦這些資源重塑了我的抽象思維《領(lǐng)域驅(qū)動設(shè)計》Eric Evans《設(shè)計模式》GoF《重構(gòu)》Martin Fowler《整潔架構(gòu)》Robert C. Martin《程序員修煉之道》最后分享一個真實案例去年重構(gòu)的報表生成系統(tǒng)通過抽象出數(shù)據(jù)源→轉(zhuǎn)換→渲染的管道模式將新增報表類型的開發(fā)時間從3天縮短到2小時。這讓我深刻體會到好的抽象不是增加復(fù)雜度而是把復(fù)雜性裝進(jìn)合適的盒子里讓使用者只需關(guān)心自己那部分。 從業(yè)務(wù)邏輯到代碼實現(xiàn)：抽象思維的四個層次與實踐技巧
1. 老代碼引發(fā)的思考為什么我們需要重新審視開發(fā)思路那天整理舊項目時我翻出了五年前寫的一段業(yè)務(wù)邏輯代碼。當(dāng)時為了趕進(jìn)度我直接按照產(chǎn)品文檔的要求把每個功能點都實現(xiàn)了出來?，F(xiàn)在回頭看那些代碼就像是用膠帶粘起來的積木——雖然能用但牽一發(fā)而動全身。最典型的是一個訂單狀態(tài)流轉(zhuǎn)的功能我寫了將近800行的if-else嵌套現(xiàn)在要加個新狀態(tài)得把整個文件重寫一遍。這讓我意識到很多開發(fā)者包括當(dāng)年的我常犯的一個錯誤拿到需求就急著寫具體實現(xiàn)。我們太關(guān)注怎么做而忽略了更重要的為什么要這樣做。就像建房子先打地基一樣寫代碼前應(yīng)該先理清業(yè)務(wù)邏輯的本質(zhì)。提示下次接到新需求時試著先問三個問題這個功能的核心目標(biāo)是什么它與現(xiàn)有系統(tǒng)的關(guān)系如何未來可能有哪些變化2. 抽象思維的四個層次從業(yè)務(wù)到代碼的完整路徑2.1 第一層業(yè)務(wù)概念抽象最近接手的一個電商優(yōu)惠券系統(tǒng)就是個好例子。產(chǎn)品經(jīng)理最初的需求文檔里提到了滿減券、折扣券、贈品券等十幾種類型。如果直接照搬這些具體類型去建模代碼很快就會變得難以維護(hù)。我的做法是找出所有券類型的共性都有有效期、使用條件、優(yōu)惠效果識別變化點條件判斷邏輯如滿X元和優(yōu)惠計算方式如減Y元建立核心抽象Coupon券基類、Condition條件接口、DiscountStrategy優(yōu)惠策略接口interface ICondition { isSatisfied(order: Order): boolean; } interface IDiscountStrategy { applyDiscount(order: Order): void; } abstract class Coupon { constructor( public conditions: ICondition[], public strategy: IDiscountStrategy ) {} validate(order: Order) { return this.conditions.every(cond cond.isSatisfied(order)); } apply(order: Order) { if (this.validate(order)) { this.strategy.applyDiscount(order); } } }2.2 第二層流程控制抽象在開發(fā)一個文件導(dǎo)入功能時我發(fā)現(xiàn)雖然文件格式CSV/Excel/JSON不同但處理流程高度一致驗證→解析→轉(zhuǎn)換→存儲。于是設(shè)計了這樣的流程控制器abstract class FileProcessor { async process(file: File) { await this.validate(file); const data await this.parse(file); const entities this.transform(data); return this.save(entities); } abstract validate(file: File): Promisevoid; abstract parse(file: File): PromiseRawData; abstract transform(data: RawData): Entity[]; abstract save(entities: Entity[]): Promisevoid; }這樣新增格式時只需繼承這個基類實現(xiàn)四個方法無需改動現(xiàn)有流程代碼。2.3 第三層設(shè)計模式的應(yīng)用在消息通知系統(tǒng)中我最初為每種通知類型郵件、短信、站內(nèi)信寫了獨立的方法。當(dāng)需要支持新渠道如企業(yè)微信時發(fā)現(xiàn)要修改多處發(fā)送邏輯。用策略模式重構(gòu)后interface NotificationStrategy { send(user: User, message: string): Promisevoid; } class NotificationService { private strategies new Mapstring, NotificationStrategy(); register(type: string, strategy: NotificationStrategy) { this.strategies.set(type, strategy); } async notify(user: User, type: string, message: string) { const strategy this.strategies.get(type); if (!strategy) throw new Error(Unsupported type: ${type}); return strategy.send(user, message); } } // 使用 service.register(email, new EmailStrategy()); service.register(sms, new SMSStrategy()); // 新增渠道只需添加實現(xiàn)類并注冊2.4 第四層領(lǐng)域驅(qū)動設(shè)計實踐在供應(yīng)鏈系統(tǒng)中我嘗試用DDD劃分邊界。比如將庫存這個概念從簡單的數(shù)據(jù)庫表升級為獨立的領(lǐng)域模型class Inventory { private items: Mapstring, InventoryItem new Map(); constructor(private repository: InventoryRepository) {} async load(sku: string) { this.items.set(sku, await this.repository.findBySku(sku)); } allocate(order: Order): AllocationResult { // 復(fù)雜的庫存分配邏輯 // 包含業(yè)務(wù)規(guī)則先進(jìn)先出、批次追蹤等 } getStockLevel(sku: string): number { return this.items.get(sku)?.quantity || 0; } }這樣將業(yè)務(wù)規(guī)則封裝在領(lǐng)域?qū)ο髢?nèi)避免業(yè)務(wù)邏輯泄漏到應(yīng)用層。3. 從抽象到實現(xiàn)的五個實操技巧3.1 白板設(shè)計法我團(tuán)隊現(xiàn)在有個規(guī)矩任何新功能開發(fā)前必須先在白板上畫清楚核心實體及其關(guān)系關(guān)鍵業(yè)務(wù)流程可能的變化點最近設(shè)計支付系統(tǒng)時我們花了整整兩天在白板前討論最終確定了這樣的架構(gòu)[支付網(wǎng)關(guān)] ←→ [支付處理器] ←→ [交易核心] ↑ ↑ [風(fēng)控系統(tǒng)] [會計系統(tǒng)]這個過程中發(fā)現(xiàn)了三個重要問題退款流程需要特殊風(fēng)控規(guī)則跨境支付涉及多幣種會計處理需要支持異步通知重試機(jī)制提前發(fā)現(xiàn)這些問題節(jié)省了至少兩周的返工時間。3.2 契約先行開發(fā)在微服務(wù)項目中我習(xí)慣先用OpenAPI定義接口契約paths: /orders: post: requestBody: content: application/json: schema: $ref: #/components/schemas/OrderRequest responses: 201: description: Created content: application/json: schema: $ref: #/components/schemas/OrderResponse components: schemas: OrderRequest: type: object properties: items: type: array items: $ref: #/components/schemas/OrderItem # 其他定義...這樣做的好處前端可以并行開發(fā)mock數(shù)據(jù)明確接口邊界避免后期扯皮自動生成類型定義和文檔3.3 測試驅(qū)動抽象寫測試能倒逼出好的抽象。比如最近開發(fā)配置管理系統(tǒng)時我這樣開始describe(FeatureToggle, () { it(should return false for undefined feature, () { const toggle new FeatureToggle({}); expect(toggle.isEnabled(new-ui)).toBe(false); }); it(should respect environment-specific override, () { const toggle new FeatureToggle({ new-ui: { default: false, staging: true } }); expect(toggle.isEnabled(new-ui, staging)).toBe(true); }); });這個測試促使我設(shè)計出這樣的實現(xiàn)class FeatureToggle { constructor(private config: FeatureConfig) {} isEnabled(feature: string, env: string default): boolean { const featureConfig this.config[feature]; if (!featureConfig) return false; return featureConfig[env] ?? featureConfig.default ?? false; } }3.4 可視化建模工具復(fù)雜業(yè)務(wù)系統(tǒng)建議使用PlantUML等工具建模。這是我們最近物流系統(tǒng)的狀態(tài)圖示例startuml state 待攬收 as pending state 運輸中 as shipping state 已簽收 as delivered state 異常 as exception [*] -- pending pending -- shipping: 攬收成功 shipping -- delivered: 客戶簽收 shipping -- exception: 運輸異常 exception -- shipping: 問題解決 enduml這種可視化表達(dá)幫助團(tuán)隊達(dá)成共識也更容易發(fā)現(xiàn)狀態(tài)機(jī)設(shè)計缺陷。3.5 重構(gòu)雷達(dá)機(jī)制我們建立了代碼壞味道雷達(dá)圖定期評估重復(fù)代碼率方法復(fù)雜度類職責(zé)數(shù)量依賴關(guān)系深度當(dāng)某個指標(biāo)超標(biāo)時立即安排重構(gòu)。比如最近發(fā)現(xiàn)訂單處理器類的process方法超過了100行立即拆分為OrderValidatorOrderCalculatorOrderNotifier每個類專注單一職責(zé)代碼可讀性大幅提升。4. 常見陷阱與解決方案4.1 過度抽象問題去年我設(shè)計過一個萬能表單渲染器試圖用一套配置支持所有業(yè)務(wù)表單。結(jié)果配置復(fù)雜度反而超過了直接寫組件{ fields: [ { type: nested, conditions: [ {field: userType, operator: equals, value: vip} ], fields: [ {name: vipCode, component: Input, rules: [required]} ] } ] }教訓(xùn)是抽象應(yīng)該遵循三次法則——當(dāng)?shù)谌斡龅较嗨菩枨髸r再抽象。4.2 領(lǐng)域模型貧血癥早期我常寫出這樣的貧血模型class Order { public items: OrderItem[]; public status: string; // 只有g(shù)etter/setter } class OrderService { calculateTotal(order: Order) { // 計算邏輯放在service里 } }改進(jìn)后的充血模型class Order { private items: OrderItem[]; private status: OrderStatus; get total(): number { return this.items.reduce((sum, item) sum item.price * item.quantity, 0); } markAsPaid() { if (this.status ! pending) { throw new Error(Invalid status transition); } this.status paid; } }4.3 抽象泄漏問題有次設(shè)計緩存層時底層Redis的異常直接拋給了業(yè)務(wù)代碼class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { // Redis連接錯誤直接暴露 throw err; } } }正確的做法是封裝領(lǐng)域異常class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { throw new ProductRepositoryError(Failed to access product, err); } } }4.4 過早優(yōu)化陷阱我曾為了性能設(shè)計過極度抽象的查詢構(gòu)建器const query new QueryBuilder() .select(id, name) .from(Product) .where( new ConditionGroup(AND, [ new Condition(price, , 100), new Condition(stock, , 0) ]) ) .build();后來發(fā)現(xiàn)95%的查詢都很簡單復(fù)雜查詢直接寫SQL更清晰性能瓶頸其實在索引設(shè)計現(xiàn)在遵循YAGNI原則除非確有需要否則保持簡單。5. 個人工具箱分享5.1 抽象思維訓(xùn)練法我每周會做這樣的練習(xí)選一個日常事物如咖啡機(jī)列出其主要功能識別變化點咖啡種類、杯型等設(shè)計抽象接口想象未來可能的擴(kuò)展例如電梯系統(tǒng)的抽象練習(xí)interface ElevatorController { requestFloor(floor: number): void; getCurrentFloor(): number; getDirection(): up | down | idle; } interface SchedulingStrategy { nextFloor(requests: number[], current: number): number; }5.2 代碼評審檢查清單在我的團(tuán)隊PR模板中包含這些抽象相關(guān)檢查項[ ] 是否存在重復(fù)邏輯[ ] 新增代碼是否適合現(xiàn)有抽象[ ] 是否需要創(chuàng)建新的抽象[ ] 領(lǐng)域知識是否泄漏到應(yīng)用層[ ] 接口設(shè)計是否遵循ISP原則5.3 架構(gòu)決策記錄(ADR)我們用markdown記錄重要抽象決策# 2023-05-01 支付網(wǎng)關(guān)抽象方案 ## 狀態(tài) 已采納 ## 背景 現(xiàn)有支付對接方式支付寶、微信支付直接耦合在訂單服務(wù)中 ## 決策 引入支付網(wǎng)關(guān)抽象層┌─────────────┐ ┌──────────────┐ │ 訂單服務(wù) │───────?│ 支付網(wǎng)關(guān) │ └─────────────┘ └──────────────┘ ▲ ┌───────────────┴───────────────┐ │ │ ┌──────────────┐ ┌──────────────┐ │ 支付寶適配器 │ │ 微信支付適配器│ └──────────────┘ └──────────────┘## 影響 - 正面新增支付渠道只需實現(xiàn)適配器 - 負(fù)面增加一次調(diào)用跳轉(zhuǎn)5.4 可視化抽象工具鏈我的常用工具組合Miro用于業(yè)務(wù)流程抽象Draw.io繪制架構(gòu)圖TypeScript Playground快速驗證接口設(shè)計Jest通過測試驅(qū)動抽象Postman模擬接口契約5.5 持續(xù)學(xué)習(xí)資源推薦這些資源重塑了我的抽象思維《領(lǐng)域驅(qū)動設(shè)計》Eric Evans《設(shè)計模式》GoF《重構(gòu)》Martin Fowler《整潔架構(gòu)》Robert C. Martin《程序員修煉之道》最后分享一個真實案例去年重構(gòu)的報表生成系統(tǒng)通過抽象出數(shù)據(jù)源→轉(zhuǎn)換→渲染的管道模式將新增報表類型的開發(fā)時間從3天縮短到2小時。這讓我深刻體會到好的抽象不是增加復(fù)雜度而是把復(fù)雜性裝進(jìn)合適的盒子里讓使用者只需關(guān)心自己那部分。