建構 Symfony 專案的另一種方法

MVC 服務架構在 Symfony 專案中非常常見，感覺像是唯一的方法。它簡單、熟悉、有效……直到它不起作用為止。隨著專案的成長，裂縫開始顯現：業務邏輯無所不在，應用程式行為不清楚，維護程式碼變得痛苦。雖然這是最常見的方法，但 Symfony 並不強迫您堅持使用它。

如果有更好的方法呢？

---

使用 MVC 服務架構的挫折

 

領域邏輯無所不在

隨著專案的發展，業務邏輯往往會分佈在整個程式碼庫中。專案的每一層——控制器、服務、表單、實體——最終都包含網域模型的各個部分。這使得專注於任何特定部分變得越來越困難。

 

專案邊界不明確

當您的架構是圍繞技術層組織的時，隨著專案的發展，識別不同上下文之間的清晰邊界變得更加困難。這種缺乏清晰度可能會導致緊密耦合的程式碼和維護挑戰。

 

項目行為不明確

由於預設架構強調技術層，因此理解專案的行為變得相當具有挑戰性。您可能會推斷某些實體由特定服務管理或猜測資料庫模式，但專案的實際行為（最重要的方面）仍然不清楚和隱含。

 

不同的生命週期

當業務邏輯分散在整個專案中並與實作細節混合時，很難獨立地發展它們。隨著時間的推移，業務邏輯的生命週期往往比實作細節（例如框架、第三方 API 或資料庫）的生命週期長得多。每當依賴項中發生哪怕是很小的更改時，這種不匹配都會迫使您重寫大部分程式碼。

---

建構架構的更好方法

 

隔離業務邏輯

為了在需要時更容易專注於業務邏輯，第一步是將其與專案的其餘部分隔離。為此，請建立一個 Domain 資料夾。該資料夾成為專案的核心，其中業務邏輯使用純 PHP 物件進行建模，不依賴實作細節。雖然專案的其餘部分依賴於此資料夾，但 Domain 資料夾不依賴任何人。

在「域」資料夾內，文件應按域目的而不是技術目的進行分組。這意味著這裡沒有實體、服務或控制器資料夾，只有與功能或網域概念相對應的資料夾名稱。

 

域的前門

專案最重要的方面是它做什麼，它可以處理的操作。這些操作代表了專案的行為，並且應該作為存取業務邏輯的唯一方法。為了反映這一點，請建立一個 Application 資料夾，明確展示專案的所有行為。例如，作為專案的新開發人員，我應該能夠透過查看此資料夾一眼就了解該專案能夠做什麼。

 

連結外部世界

使用 App 和 Domain 資料夾，可以輕鬆專注於業務邏輯。然而，在某些時候，這個業務邏輯需要與外部系統互動。要處理此問題，請建立第三個名為 Infrastruct 的資料夾，其中包含所有實作細節，例如特定於框架的程式碼、資料庫連線和程式庫。

Infra設施資料夾中的檔案取決於App和Domain檔案。例如，他們可能從 App 資料夾呼叫應用程式處理程序或實作 Domain 資料夾中定義的介面。

具體來說，在 Symfony 中，這涉及修改 Controller 資料夾並聲明哪些服務實作哪些介面。

# config/routes.yaml

controllers:
    resource:
        path: ../src/Catalog/Infrastructure/Controller/
        namespace: App\Catalog\Infrastructure\Controller
    type: attribute

 

揭示界限

隨著專案的發展，您可能會注意到業務邏輯的某些部分值得在架構中擁有自己的空間。一個好的指標是同一個術語根據上下文開始具有不同的意義。例如，「產品」一詞可能指的是工廠產品、倉庫產品或電子商務產品，每種產品都需要自己的模型。神物也可以是一個很好的指標； User 類別在 Symfony 專案中經常出現此類問題。

當這種情況發生時，就該將其提取出來並讓其業務邏輯獨立演化。

一些上下文將構成您專案的核心，而其他上下文將支持它。通用上下文（例如 Auth）可以使用更簡單的架構，因為它們不是您的網域的中心

在這張圖中，我們可以看到 Auth 上下文使用標準的 Symfony 結構，Order 和 Catalog 上下文使用以域為中心的架構，Shipping 上下文使用以功能為中心的架構。

 

增量模組化

如果特定情境成長到需要獨立擴充的程度，請考慮將其拆分為單獨的部署單元。

但是，不要急於進行這一步。首先使您的專案模組化，如果您發現上下文需要單獨擴展，請單獨部署它。
只有在出現組織挑戰時才拆分程式碼庫，例如兩個團隊在同一程式碼庫上難以協作。

走得更遠

• Simon Brown - 模組化巨石

---

概念

在探索這些解決方案時，我們應用了一些製程概念。讓我們命名並簡要解釋它們，以便您可以更深入地了解每一個。

 

無所不在的語言

這個不尋常的術語背後隱藏著一個非常簡單的概念。通用語言是您的團隊用來描述領域模型的詞彙。這些詞彙應該記錄在案，並在產品對話、程式碼庫等各處一致使用。

具體來說，在有界上下文的根部創建一個 markdown 文件，並將產品人員、領域專家和技術團隊聚集在一起來定義專案的每個概念。

走得更遠

• Eric Evans - DDD - 第 2 章：溝通與語言的使用
• 馬丁·福勒 - 無所不在的語言

 

有界上下文

有界上下文定義了專案內的語言邊界，分隔了系統中通用語言不再對齊的部分。上下文地圖和事件風暴等工具可以幫助識別這些邊界。

有界上下文是一個抽象概念；它可以透過多種方式實現，從模組化整體中的簡單資料夾到微服務架構中的叢集。

走得更遠

• Eric Evans - DDD - 第四部分：策略設計
• Vaughn Vernon - IDDD - 第 2 章：域、子域和有界上下文
• Martin Fowler - 有界上下文

 

連接埠和適配器、六邊形、洋蔥形和簡潔架構

所有這些架構的目的是將業務邏輯與實作細節隔離。無論您使用連接埠和適配器、六角形還是乾淨架構，核心思想都是使業務邏輯框架與框架無關且易於測試。

一旦您記住了這一點，就會有各種各樣的實現，而最好的實現取決於您的上下文和偏好。這種架構的一個主要優點是，透過隔離您的業務邏輯，它可以實現更有效率的測試。

走得更遠

• Alistair Cockburn - 六角形建築
• 叔叔鮑伯 - 乾淨的建築
• Herberto Graca - DDD、六邊形、洋蔥、清潔、CQRS，…我如何將它們放在一起

 

尖叫建築

組織資料夾和文件以「尖叫」業務邏輯的想法稱為尖叫架構。這個概念強調程式碼的結構應該使專案的目的立即清晰。目標是讓新開發人員一目了然地了解專案的用途。

我強烈建議閱讀鮑伯叔叔關於這個主題的文章 - 他與房屋規劃的比較特別富有洞察力。

走得更遠

• 叔叔鮑伯 - 尖叫建築

 

垂直切片架構

垂直切片按功能組織您的項目，允許每個功能獨立發展。它使您能夠根據複雜性和成熟度將不同的架構應用於不同的功能。

雖然這個想法很有趣，但它需要高技能的工程師來有效地實現和維護這樣的架構。

走得更遠

• Jimmy Bogard - 垂直切片架構
• CodeOpinion - 垂直切片架構，而不是層！

---

最後的想法

建構 Symfony 專案的方式對其可擴展性、可維護性和清晰度有著深遠的影響。透過隔離您的業務邏輯並使行為明確，您將創建一個更易於理解和發展的系統。

如果您對這些想法不熟悉，請不要擔心，軟體工藝是一個旅程，而不是目的地。這些概念一開始可能看起來令人難以接受，但每個概念都將幫助您為您的業務創造更多價值。

有疑問或想分享您的經驗嗎？將它們放入評論中！請繼續關注下一篇文章？

以上是建構 Symfony 專案的另一種方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！