l

2016年8月11日 星期四

領域驅動設計學習筆記(1):學習的切入角度(上)

August 10 21:10~23:16

螢幕截圖 2016-08-10 22.52.35

▲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之前畫過的圖。

螢幕截圖 2016-08-10 21.55.13

 

對於已經熟悉傳統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,可以看出一些別人看不到的弦外之音。

***

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

沒有留言:

張貼留言