許多年前，我們開始了一個新的長期專案，首先，我們基於洋蔥架構構建了它的架構。在幾個月內，這種風格開始顯示出裂縫，我們從這種架構轉向CQRS。隨著轉向CQRS，我們開始圍繞垂直切片而不是層（無論是平面還是同心，它仍然是層）構建我們的架構。從那以後，在過去7到8年左右的時間裡，圍繞垂直切片架構構建應用程式和系統的所有方式一直是我們獨有的方法，我無法想象回到分層架構方法的限制。

傳統的分層/洋蔥/清潔架構在其目標是單體的：

這種架構方式問題是實際上只適用於系統中的少數典型請求。此外，我傾向於看到這些架構嚴重擬合，嚴格遵守依賴關係管理規則。在實踐中，我發現這些規則很少有用，並且你開始得到很多關於真正不應該被抽象的抽象（控制器必須與必須使用儲存庫的服務進行對話）。

相反，我想對我的系統採用量身定製的方法，我將每個請求視為如何處理其程式碼的獨特用例。因為我的系統整齊地分解為“命令”請求和“查詢”請求（HTTP-land中的GET與POST / PUT / DELETE），所以向垂直切片架構的移動使我使用了CQRS。

什麼是“垂直切片架構”？在這種風格中，我的架構是圍繞不同的具體請求功能而構建的，通過這種方法，我們的每個垂直切片都可以自行決定如何最好地滿足請求：

(banq注：對於獲取訂單，直接使用ORM轉換為DTO，對於訂單細節使用原生SQL轉換為DTO，對於發票，使用基於聚合根的事件溯源，取消訂單使用儲存過程，這是一種微服務風格)

在所謂正常的“n層”或六邊形或任何架構中，通過垂直切片移除這些層障礙，並沿著變化軸聚合在一起：

在應用程式中新增或更改功能時，通常會在應用程式中涉及到許多不同的“層”。現在改為沿著切片垂直將這些功能聚合在一起。

最小化切片之間的耦合，並最大化切片內的聚合。

通過這種方法，大多數抽象都消失了，我們不需要任何型別的“共享”層抽象，如儲存庫，服務，控制器。有時我們仍需要這些工具，但我們將交叉切片邏輯共享保持在最低限度。

通過這種方法，我們的每個垂直切片都可以自行決定如何最好地滿足請求。

“ 企業架構模式”一書中的舊域邏輯模式不再需要成為應用程式範圍內的選擇。相反，我們可以從簡單的（事務指令碼）開始，並簡單地重構從我們在業務邏輯中看到的程式碼氣味中出現的模式。新功能只新增程式碼，您不會更改共享程式碼並擔心副作用。非常自由！

但是，這種方法有一些缺點，因為它確實假設您的團隊瞭解程式碼氣味和重構。如果您的團隊不理解“服務”在將邏輯推送到領域時自己卻做得太多相關業務邏輯事情，那麼這種模式可能不適合您。（banq注：服務類似餐廳服務員，服務員不應該做決定，只是協調者，當然如果你想退菜，服務員會決定說：不能退，菜已經燒了。）

如果您的團隊確實理解了重構，並且能夠識別何時將複雜的邏輯推入域，進入DDD服務應該是什麼，並且熟悉其他Fowler / Kerievsky重構技術，那麼您會發現這種架構風格能夠遠遠超過傳統的分層/同心架構。