從分層架構到DDD。我的遷移和切割巨石的經歷

今天我們將討論後端應用程式的架構，並比較兩種流行的專案結構方式：onion 和 DDD。我將告訴您第二種方法相對於第一種方法的優點以及我最近將專案轉移到六邊形架構的經驗。本文適合已經使用過分層架構並希望了解更多內容的人（例如，開始使用微服務）。

讓我們從分層架構開始。分層，也稱為洋蔥架構，是我們將整個應用程式分層的架構。每一層都有自己的功能和明確的目的。例如與資料庫的互動：這樣的層應該只包含與資料庫互動的功能，而沒有其他功能。不應與客戶端或任何其他功能進行互動。

在分層架構中，後端通常有 3 個主要層：用於與儲存互動、應用程式邏輯和代表層。

這是一個典型的三層架構，一切都非常簡單。請求經過各個層，取得最終的形式（儲存中的請求），回應進行回程，變成某種方便客戶端的格式（JSON、XML等）。

我在我的所有專案和我參與的新創公司中已經使用這個架構很長時間了。在小型寵物專案中，這種方法確實有效且不會引起問題，但在較大的專案中，混亂就開始了。

分層架構的主要原則之一是能夠用相似的層替換任何層，因此根本不需要更改其他層。但實際上，專案中出現的實體越多，遵守起來就越困難。

一開始會出現太多的依賴關係，並且控制它們變得越來越困難。這意味著對整體架構的忽視（畢竟，洋蔥是一個整體架構）。負載分配不正確，應用程式出現過載。此外，各層開始混合——隔離應用程式邏輯變得越來越困難。擴展應用程式變得越來越困難，依賴性使調試變得地獄，開發速度大大減慢。火上澆油的是嚴格的架構模式限制了開發人員的能力。如果您正在閱讀本文，您可能已經遇到過這種情況。我們的專案也出現了同樣的情況。

顯然，在這種情況下，有必要削減單體架構，切換到另一種架構並引入更自由的模式。我們選擇了 DDD，這似乎是一個顯而易見的解決方案。 DDD （領域驅動設計，六邊形架構） 是一種基於抽象構建的微服務（儘管它可以用作整體）架構。如果您只有使用分層架構的經驗，那麼作為一個粗略的示例，您可以想像相同的三層架構，其中不是與存儲交互的層，而是與所有技術交互的層，並且還有具有抽象的單獨層。抽象通常是 DDD 中的主要內容。這些抽像以及輔助工具和演示實體（模板、圖表）與應用程式分離，因此架構如下所示：

heskagonal 架構相對於分層架構的主要優點是可擴充性。因為依賴關係更少，所以實現新特性、新參數和新功能要容易得多。

起初，這種結構對我來說完全不合邏輯，但是在切換到DDD 的過程中，我發現它變得更容易編寫，因為甚至從應用程式的最底層也完全刪除了基礎設施，並且有依賴性更少。每個實體甚至都出現了某種不合理的解脫和突然的行動自由。現在在我看來，這種方法比分層架構更符合邏輯。

但是你需要記住，如果專案中有2-3 個實體，這樣的架構就沒有意義，因為DDD 主要用作具有大量依賴項的應用程式中的微服務架構，這根本無法在具有2 -3 個實體的小型寵物項目。在某些地方，即使是簡單的線性架構就足夠了。一般來說，不必要地使用不同的技術和實踐是不好的做法，除非您決定嘗試學習。

P.S.你需要迷上 TGC：https://t.me/dmkjfss

以上是從分層架構到DDD。我的遷移和切割巨石的經歷的詳細內容。更多資訊請關注PHP中文網其他相關文章！