Chris Patuzzo近期在一次演講中介紹了領域驅動設計（DDD）的原則，并結合一個基于Ruby on Rails的真實項目進行講解。在這次項目之前，Chris所在的團隊為重新設計公司的主營網站所做的兩個概念驗證都因為可伸縮性方面的問題而失敗了。因此，業務主管部門決定在這一次嘗試中采取一種更為敏捷的、增量式的方法，他們受到了DDD的啟發，在這次重啟的開發過程中全力促進開發者與領域專家的交流。

\\

Patuzzo是Which?的技術主管。在他看來，DDD的要點是捕捉到業務的概念，軟件的構建需要圍繞著對業務的理解而展開。在這次項目重啟的過程中，開發者開始學會與領域專家進行深入交流，以試圖理解整個業務的實際行為。在此基礎上設計出合適的領域模型，并找到系統中存在的各個邊界。按Patuzzo的經驗來看，在具有清晰的邊界劃分的系統中開展工作要輕松許多。通過保持關注分離，系統將更易于理解，如果之后需要將系統中的某些部分提取出來，實現起來也會更簡單。

\\

DDD建議將問題分解為多個層，每一層各司其職，例如表示層、領域層以及基礎設施層。Patuzzo特別提到在進行Rails開發時存在著一種常見的實踐，即將領域層與基礎設施層合并在一起，這種方式顯然違背了DDD的建議。除了分層架構外，另一種選擇是由Alistair Cockburn定義的多邊形架構（Hexagonal architecture），但Patuzzo并不強烈主張這種架構風格，他認為這種架構可能會令人迷惑。他表示，這些架構有助于管理系統的復雜度，保持對核心領域的專注，但他也承認這些思想對于Ruby社區來說還比較新鮮，需要一定的時間去適應。

\\

衡量復雜度的一種方式是計算對象間的交互，通過使用聚合與聚合根，可以將這種交互限制在聚合之內，以及聚合根之間的交互，從而將這種交互的頻率減至最低。Patuzzo將其稱為系統的表面區域。Ruby項目通常會使用活動目錄（Active Record）這種設計方式，因此每個類都表現為全局的常量，可以在系統中的每一處隨意訪問。為了繞開這個問題，開發者通常會用聚合的名稱作為類名的前綴。通過將系統功能分解為聚合，使對象間的通信顯得更為結構化。這種新的設計方式對于團隊來說確實引入了一個陡峭的學習曲線，這一部分在開發過程中所產生的分歧也是最大的。但在項目的回顧會議中，Patuzzo對于最終的結果表示很滿意。

\\

Patuzzo在總結中表示：雖然全新的開發過程為開發者帶來了一些負擔，但好處也很明顯。開發者學到了DDD的基本模式與思想、如何將架構分解為多個層、關注分離的思想、以及如何設計一個能夠應對變化的系統。由于新系統是基于一個能夠充分表現業務需求的模型而建立的，因此他相信他的團隊將能夠更好地滿足新的需求。

\\

查看英文原文：Experiences Introducing DDD in a Project

總結

以上是生活随笔為你收集整理的在项目中引入领域驱动设计的经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。