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

\\

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

\\

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

\\

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

\\

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

\\

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。