2023年Stack Overflow調(diào)研顯示，67%的.NET開發(fā)者仍在把倉儲接口和實現(xiàn)塞在同一層。這不是技術(shù)債，是架構(gòu)認知的代際斷層。

基礎設施層（Infrastructure Layer）被戲稱為"最無聊的層"，卻藏著軟件設計中最持久的爭議。它本該是技術(shù)細節(jié)的隔離帶，卻成了耦合的重災區(qū)。

從N層到六邊形：一場持續(xù)20年的遷徙

早期的N層架構(gòu)里，基礎設施層是鏈條末端。業(yè)務層直接操作數(shù)據(jù)庫對象，倉儲接口和實現(xiàn)擠在同一層——這在CRUD時代完全夠用。

但現(xiàn)代系統(tǒng)的技術(shù)棧復雜度翻了十倍。消息隊列、外部API、緩存、對象存儲、日志框架……每個都是潛在的泄漏點。

六邊形架構(gòu)（Hexagonal Architecture）和整潔架構(gòu)（Clean Architecture）的出現(xiàn)，本質(zhì)上是一次"方向反轉(zhuǎn)"：讓業(yè)務核心成為宇宙中心，基礎設施變成可替換的插件。

關鍵轉(zhuǎn)變：倉儲接口被抽離到領域?qū)樱―omain Layer）或應用層（Application Layer），基礎設施層只保留實現(xiàn)。

這解決了三個頑疾：業(yè)務邏輯可以獨立編譯測試、技術(shù)細節(jié)不再向上滲透、替換數(shù)據(jù)庫時不用重寫業(yè)務代碼。

那些藏在代碼庫里的"智能陷阱"

我見過最隱蔽的反模式是"智能倉儲"（Smart Repository）——在倉儲里塞業(yè)務邏輯，比如自動計算折扣后存儲、或者根據(jù)狀態(tài)觸發(fā)副作用。

表面看是代碼復用，實際是職責錯位。倉儲變成了披著技術(shù)外衣的業(yè)務層，測試時需要連數(shù)據(jù)庫一起啟動，單元測試淪為集成測試。

另一個常見坑是"領域泄漏的工具類"。一個處理貨幣計算的`MoneyUtils`，內(nèi)部偷偷調(diào)用了外部匯率服務。業(yè)務代碼以為自己在用純函數(shù)，實際上被網(wǎng)絡延遲和第三方故障綁架。

框架驅(qū)動設計（Framework-Driven Design）更隱蔽。團隊選了某個ORM后，實體類被迫繼承框架基類、屬性被打上特性標簽（Attribute）。領域模型淪為持久化模型的附庸，換ORM等于重寫核心業(yè)務。

邊界劃分的實戰(zhàn)法則

判斷接口歸屬有個樸素標準：誰需要依賴它？

應用層需要持久化數(shù)據(jù) → 倉儲接口屬于應用層或領域?qū)印；A設施層實現(xiàn)接口 → 依賴關系向內(nèi)指向核心，而非向外擴散。

端口與適配器（Ports and Adapters）的命名很貼切：業(yè)務核心定義"我要什么"（端口），基礎設施回答"我怎么做"（適配器）。

日志和緩存這類橫切關注點更微妙。如果日志格式包含業(yè)務語義（如"用戶{userId}下單失敗"），接口應由應用層定義；純技術(shù)日志（如SQL執(zhí)行時間）則可留在基礎設施層。

外部服務調(diào)用是重災區(qū)。我見過團隊在基礎設施層直接返回供應商DTO，業(yè)務層被迫消化第三方字段命名。正確的切口：基礎設施層做防腐轉(zhuǎn)換（Anti-Corruption Layer），進出都是領域?qū)ο蟆?/p>

測試策略是檢驗標準。理想的領域?qū)訙y試應該能在內(nèi)存中跑完，啟動時間以毫秒計。如果跑測試需要Docker Compose，說明邊界畫錯了。

一個仍在演進的共識

整潔架構(gòu)提出者Robert C. Martin近年修正過早期觀點：接口定義的位置沒有絕對答案，取決于變更頻率和團隊規(guī)模。

小團隊、單體應用、技術(shù)棧穩(wěn)定——接口放基礎設施層，減少抽象層數(shù)。多團隊、微服務、技術(shù)棧可能替換——接口必須靠近業(yè)務核心。

這不是非黑即白的選擇，是權(quán)衡后的刻意設計。

微軟eShopOnContainers示例項目把倉儲接口放在應用層，基礎設施層用EF Core實現(xiàn)。但GitHub上有個高星Fork把接口下沉到領域?qū)樱驗閳F隊需要支持MongoDB和SQL Server雙寫——同一套代碼，不同邊界決策。

你的代碼庫里，倉儲接口現(xiàn)在躺在哪一層？最近一次替換數(shù)據(jù)庫或框架時，你改了百分之多少的文件？