MVC 服務架構在 Symfony 專案中非常常見，感覺像是唯一的方法。它簡單、熟悉、有效……直到它不起作用為止。隨著專案的成長，裂縫開始顯現：業務邏輯無所不在，應用程式行為不清楚，維護程式碼變得痛苦。雖然這是最常見的方法，但 Symfony 並不強迫您堅持使用它。
如果有更好的方法呢？
隨著專案的發展，業務邏輯往往會分佈在整個程式碼庫中。專案的每一層——控制器、服務、表單、實體——最終都包含網域模型的各個部分。這使得專注於任何特定部分變得越來越困難。
當您的架構是圍繞技術層組織的時，隨著專案的發展，識別不同上下文之間的清晰邊界變得更加困難。這種缺乏清晰度可能會導致緊密耦合的程式碼和維護挑戰。
由於預設架構強調技術層，因此理解專案的行為變得相當具有挑戰性。您可能會推斷某些實體由特定服務管理或猜測資料庫模式，但專案的實際行為（最重要的方面）仍然不清楚和隱含。
當業務邏輯分散在整個專案中並與實作細節混合時，很難獨立地發展它們。隨著時間的推移，業務邏輯的生命週期往往比實作細節（例如框架、第三方 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 上下文使用以功能為中心的架構。
如果特定情境成長到需要獨立擴充的程度，請考慮將其拆分為單獨的部署單元。
但是，不要急於進行這一步。首先使您的專案模組化，如果您發現上下文需要單獨擴展，請單獨部署它。
只有在出現組織挑戰時才拆分程式碼庫，例如兩個團隊在同一程式碼庫上難以協作。
在探索這些解決方案時，我們應用了一些製程概念。讓我們命名並簡要解釋它們，以便您可以更深入地了解每一個。
這個不尋常的術語背後隱藏著一個非常簡單的概念。通用語言是您的團隊用來描述領域模型的詞彙。這些詞彙應該記錄在案，並在產品對話、程式碼庫等各處一致使用。
具體來說，在有界上下文的根部創建一個 markdown 文件，並將產品人員、領域專家和技術團隊聚集在一起來定義專案的每個概念。
有界上下文定義了專案內的語言邊界，分隔了系統中通用語言不再對齊的部分。上下文地圖和事件風暴等工具可以幫助識別這些邊界。
有界上下文是一個抽象概念；它可以透過多種方式實現，從模組化整體中的簡單資料夾到微服務架構中的叢集。
所有這些架構的目的是將業務邏輯與實作細節隔離。無論您使用連接埠和適配器、六角形還是乾淨架構，核心思想都是使業務邏輯框架與框架無關且易於測試。
一旦您記住了這一點，就會有各種各樣的實現，而最好的實現取決於您的上下文和偏好。這種架構的一個主要優點是，透過隔離您的業務邏輯，它可以實現更有效率的測試。
組織資料夾和文件以「尖叫」業務邏輯的想法稱為尖叫架構。這個概念強調程式碼的結構應該使專案的目的立即清晰。目標是讓新開發人員一目了然地了解專案的用途。
我強烈建議閱讀鮑伯叔叔關於這個主題的文章 - 他與房屋規劃的比較特別富有洞察力。
垂直切片按功能組織您的項目，允許每個功能獨立發展。它使您能夠根據複雜性和成熟度將不同的架構應用於不同的功能。
雖然這個想法很有趣，但它需要高技能的工程師來有效地實現和維護這樣的架構。
建構 Symfony 專案的方式對其可擴展性、可維護性和清晰度有著深遠的影響。透過隔離您的業務邏輯並使行為明確，您將創建一個更易於理解和發展的系統。
如果您對這些想法不熟悉，請不要擔心，軟體工藝是一個旅程，而不是目的地。這些概念一開始可能看起來令人難以接受，但每個概念都將幫助您為您的業務創造更多價值。
有疑問或想分享您的經驗嗎？將它們放入評論中！請繼續關注下一篇文章？
以上是建構 Symfony 專案的另一種方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！
