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

August 11 11:00~13:03

 

昨天提到學習領域驅動設計（Domain-Driven Design；DDD）的兩個切入點—「物件導向分析與設計」和「Pattern Language（模式語言）」，今天繼續談其他兩個觀點。

***

軟體架構

對DDD有興趣是因為前一陣子讀了幾篇微服務架構（Microservice Architecture）的文章提到使用DDD作為設計Microservice的方法。DDD中的Bounded Context成為Microservice自然的邊界，藉由DDD的Context Map可以分析多個Bounded Context的整合關係，剛好和Microservice完美匹配。

鄉民們可以把Microservice的運作模式想像成歐盟成立之前的狀況，每個歐洲國家（例如法國、德國、義大利、西班牙、荷蘭）在歐洲地圖上各自都是一個Bounded Context，擁有自己的語言（Ubiquitous Language）、貨幣、邊界管理（出入境審查）、法規等。在電腦世界可以用Microservice來「實作」每一個國家，每一個Microservice（國家）都是一個自治單位，可以獨立運作、修改、更新、佈署（註：這些特性都是DevOps想要獲得的好處）。國與國之間可能存在著相依性，例如德國要從義大利進口橄藍油，這時候就牽涉到不同語言（德語和義大利語）、不同貨幣、不同法規（橄藍油檢驗標準）之間的轉換工作。針對兩個不同「國家」（Bounded Context）之間的關係DDD整理成以下九種pattern：Partnership、Shared Kernel、Customer-Supplier、Conformist、Anticorruption Layer、Open Host Service、Published Language、Separate Ways、Big Ball of Mud。

可想而知GoF的Facade、Adapter這兩個pattern在Microservice中會經常使用到，前者用來規範介面以便提供Microservice的內部服務給外界使用，後者用來轉接兩個Microservice之間的介面（包含資料格式與通訊協定）。一群Microservice一起提供服務的溝通架構很像傳統的Pipe and Filter軟體架構模式，在〈Microservices〉這篇文章中稱為「Smart endpoints and dumb pipes」。

剛剛提到的是Bounded Context之間的架構，軟體架構的問題還有很多可以討論，例如Bounded Context內部的架構該如何設計？DDD希望把傳統上一整坨（monolith）的軟體系統拆分成由若干個Bounded Context的軟體實作所組成的分散式、鬆散耦合的軟體系統。這個特性本質上很適合現在的虛擬化與雲端計算架構，但是如果要開發桌上型應用軟體，在架構上應該要如何調整才可以在系統執行效率與鬆散耦合之間獲得平衡？套用DDD對於軟體架構的設計會變得更加簡單、靈活，還是限制更多？Ubiquitous Language的演進如何影響軟體架構的演進？

***

開發流程

最後一個重大議題是開發流程。DDD在本質上是一種很適合敏捷開發的方法，DDD首先將一個大系統切分成若干個Bounded Context，每一個Bounded Context只交給一個團隊開發（一個團隊可以同時負責好幾個Bounded Context的開發工作）。每個Bounded Context之間有著清楚的介面，可以獨立運作。這一點對於將敏捷開發拓展到大型軟體專案上有著天生的自然對應關係。

懂Scrum的鄉民可以想成一個Scrum團隊負責開發一個或若干個Bounded Context，Bounded Context內部的開發工作是採用end-to-end的切割方式。DDD對於想要將敏捷開發進一步推展到DevOps也是很有幫助，假設每一個Bounded Context都被開發成Microservice，一個軟體系統由一群獨立運作、修改、佈署的Microservice所組成。加上Microservice的架構本身對於錯誤處理、各種監控（Monitorig）的要求，讓維運團隊可以很靈活的管理這些服務。

以上所說都是「理論上」的好處。如何在迭代式開發流程像Scrum或流式開發方法像Kanban中有效的套用DDD，也是值得觀察的重點。

***

結論

最近DevOps議題很熱門，經常在網路上看到有人討論「要如何導入DevOps？」有些公司高層認為DevOps跟「工業4.0」很像，買買機器人，把生產線自動化就可以了。所以老闆問工程師：「需要哪些自動化工具讓我們的佈署時間可以像DevOps廣告上說得一樣從幾天縮短成幾分鐘？從幾個月釋出一次變成一天釋出好幾十次？」如果這些工具都是免費的開源軟體就更棒了！

錯了、錯了！有人說DevOps不只是工具自動化的問題，而是需要改變公司文化，所以公司應該先從敏捷與精實開發精神開始著手。很有道理，但是還少了些什麼。你的軟體架構如果還停留在「一整塊大石頭」的狀況，就算敏捷開發流程面很熟悉、自動化工具用到爐火純青，整個企業對於「改變」的反應很快會達到一個臨界點之後就快不起來，因為最後會卡在「軟體變成硬體」這個問題上面。

更糟的還不只如此。對於改變的反應要靈活，開發團隊與Product Owner以及業務人員之間的溝通要順暢。這個「溝通順暢」不只是坦誠對話、開會的藝術、人際溝通這種層面的問題，而是如何讓一群人可以在一個「共通語言」（Common Language）上緊密且有效率的合作。

這個共通語言可以是Alexander的Pattern Language，或是DDD所提到的Ubiquitous Language—一個貫穿分析、設計、實作、測試、維運的共通語言。

唯有打通文化（人的問題）與技術這兩個軟體開發的任督二脈，才可能達到理想的彼岸。DDD可以視為一種對於打通「軟體開發任督二脈」的嘗試。對Teddy而言，最棒的是DDD用Pattern Langauge的方法來打通任督二脈，讓之前學過的各種pattern，像是process pattern、analysis pattern、architecture pattern、design pattern、test pattern、implementation pattern、CI/CD pattern、HCI pattern等等，可以在同一個舞台上形成開發團隊的Ubiquitous Language。

***

友藏內心獨白：英國脫歐之後變回Microservice。