領域驅動設計學習筆記（1）：學習的切入角度（上）

August 10 21:10~23:16

▲Kent Beck叔叔說每一位深思熟慮的軟體開發人員的書架上都要有這本書

 

昨天提到最近準備把領域驅動設計（Domain-Driven Design；DDD）應用在某專案上，這一系列文章用來記錄學習DDD的過程與心得。因為還在學習中，所以文章內容僅反應當下理解與誤解的狀態，內容可信度請鄉民們自行判斷。

在〈[還少一本書] Domain-Driven Design Distilled〉稍為介紹過DDD，沒讀過的鄉民可以先看一下。今天談談Teddy學習DDD的切入角度。

***

物件導向分析與設計

第一個切入角度是從物件導向分析與設計（object-oriented analysis and design；OOAD）方法來看待DDD。DDD應該可以被歸類為一種OOAD方法，但是DDD所採用的方法和Teddy以前從《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》和Unified Process（UP）學到的那一套又不太一樣。傳統OOAD的塑模（Modeling）過程有很清楚的分析、設計、實作階段，將domain model轉成design model再轉成implementation model。在DDD中則是透過開發人員與領域專家密切合作，將問題領域（problem domain）切割出子領域（subdomain），然後決定每個子領域的Bounded Context作為塑模的邊界範圍。在這個Bounded Context中，大家都用相同的語言來溝通需求、設計以及實作。這種語言在DDD中稱為通用語言（Ubiquitous Language）。

開發人員與領域專家可以透過scenario來溝通領域物件的特性、限制或商業規則。而這些scenario可以接著用BDD/Specification by Example/TDD的方式串接後續的開發活動。從以上說明來看，兩者之間的關係很像下面這張Teddy之前畫過的圖。

 

對於已經熟悉傳統OOAD方法的人來講，在學習DDD的時候如果可以找出兩者之間的異同之處，不但有助於理解與記憶，還可以重複使用原本的知識。

***

Pattern Language（模式語言）

第二個切入觀點是從建築師Christopher Alexander的Pattern Language方法來解讀DDD。DDD發明人Eric Evans的《Domain-Driven Design》這本書Teddy認為書名也可以改成「A Pattern Language for Domain-Driven Design」，書中pattern的寫作格式也是採用類似Alexander的格式。DDD企圖複製Alexander在建築領域應用Pattern Language的方式到軟體設計領域，如果比較《Domain-Driven Design》和GoF的《Design Patterns》便可發現GoF並沒有像Evans一樣那麼用心地「抄襲」Alexander。

看過Pattern Language文章的鄉民應該會知道這類文章標題通常是「A Pattern Langauge for XXX」，這個XXX就是這個Pattern Langauge所適用的領域。例如：

• A Pattern Langauge for Writers’ Workshops
• SCRUM: A Pattern Language for Hyperproductive Software
• A Pattern Language for Security Models
• A Pattern Language for Personal Authoring in E-Learning

Teddy認為Ubiquitous Language基本上就是由領域專案與開發人員針對某個Bounded Context所設計的Pattern Langauge，例如在《Implementing Domain-Driven Design》（IDDD）書中有一個例子包含三個Bounded Context，分別為Agile Project Management Context、Identify and Access Context、Collaboration Context。因此這三個Bounded Context的Ubiquitous Language是否可以稱為：

• A Pattern Language for Agile Project Management
• A Pattern Language for Identify and Access
• A Pattern Language for Collaboration

乍看之下好像很合理，但兩者之間又不相同，因為Ubiquitous Language並不是Pattern Language。聽起來好像是廢話，但這是一句有重點的廢話。Pattern Language顧名思義就是由一組pattern所組成的語言，但是組成Ubiquitous Language的主要元素並非pattern，而是domain model加上一些其他有的沒的東西。也許因為把每個domain model都用pattern來表達有點過於「殺雞用牛刀」，所以DDD改用以domain model為主的Ubiquitous Language作為溝通工具而不像原本Alexander的作法是用以pattern為主的Pattern Language作為溝通工具。但無論如何，採用Pattern Language的觀點來思考甚至是建構Ubiquitous Language，應該可以獲得加分效果。

對於熟悉Alexander的Pattern Langauge方法的人，用這個角度去理解DDD，可以看出一些別人看不到的弦外之音。

***

友藏內心獨白：這一切都是假的，眼睛業障重的人才看得到。