iT邦幫忙

2021 iThome 鐵人賽

DAY 25
0
自我挑戰組

馬克的軟體架構小筆記系列 第 25

30-25 之 DDD 戰略設計 1 - 戰略設計的目的

接下來我們將要開始重 DDD 的戰略設計來開始談談,別忘了戰略的重點在於 :

如何切

然後還有個金句要記錄一下 :

DDD 不看功能,而只看流程

基本上戰略設計主要有三個目的 :

  • 分析 Domain 並切成 SubDomain
  • 定義解決方案的邊界 Bounded Context
  • 定義關係 Context Map

然後完成以上戰略設計目的方法論,目前比較有名的有二個,之後的文章會談到 :

  • Event Storming
  • Domain storytelling

接下來這篇文章先來談談,這三個戰略目的。

分析 Domain 並切成 SubDomain 並且建立 統一語言 Ubiquitous Language

這個目的是理解 domain,並且將大的切成小的,才好解決,並且建立統一語言,才能在未來討論與建立軟體模型時,說一件事情,都是指同一件事情。

根據 《 中台架構與實現基於 DDD 和微服務 - 歐創新 》這本書中對 Domain 的定義為 :

Domain 是從事一種專門活動或事業的範圍

然後在這篇文章中,我看到了一個注釋,我覺得的非常有理 :

你在工作上面對的問題 + 解法 。

所以總結一下,我自已對 domain 的看法 :

Domain 是一種業務範圍,包含了問題 ( Problem Space ) 與解法 ( Solution Space )。

所以 domain 事實上是業務的『 問題 』 + 『 解法 』,但是我們開發人員很多時後的系統設計是以『 解法 』又或是說『 技術 』為基準,這也導致架構與業務是分開來的,才會發生想以『 業務 』來切『 微服務 』那麼的困難,因為根本沒有以『 業務 』為本。

基本上你待在一間公司,那間公司做的東西,對那間公司來說就是一個 domain,不過他就是個大泥球,可以想成是少數幾個人記在腦海裡的東西,但是他的範圍與要做的事情,不一定有明確的定義。而 DDD 戰略目的就是要將他定義清楚。

接下來我們要談一下這個目的下,要找到的幾樣東西 :

SubDomain

DDD 會先將這個 domain 的範圍定義好,接下來會再將它們分成 subDomain,因為要解決大問題就要從小問題開始解,最後在根據每個特性,產生出以下幾個東東 :

  • Core Domain : 最有價值、最核心、花費最大力氣在開發。
  • Supporting SubDomain : 提供 core domain 所需的功能。
  • Generic SubDomain : 所有系統都需要用到他,但不是核心,也就是說丟給外包也可以的部份。

現階段很多公司,很多單一系統所處理的 domain 已經過於龐大了,不先想辦法切分,你就會看到一團大泥球,你完全切不動,然後最慘的就是後端工程師,因為全公司平台上的 domain 都是你們做的,這導致每個部門一有事就來問你們,而如果後端工程師少的情況下,幾乎每個工程師都會變成最理解公司 domain 的人。我待過的公司就是這樣… 慘。

有時後想想新創的後端真的慘,各部門 domain 被尋問人、feature 開發人員、sre 維運人員、分析資料產出人員、mis… 我還看過有人當水電工的…

統一語言 Ubiquitous Language

簡單的說就是一個詞,每個人所理解的意思是相同的,然後之後都用這個詞來溝通與建模

如果沒有它會發生 :

  • 缺少統一語言,導致人們對其他人的語言,可能會理解錯誤,又或是需要花時間翻譯,這樣會導致在建立 domain 時可能出錯。
  • 缺少統一語言時,新成員會很難理解組員在說什麼,因為每個人都用自已的字來說明某個東西的意思。

定義解決方案的邊界 Bounded Context

目的是要知道我們所寫的程式碼 ( 解決方案 ),要處理的範圍情境是什麼

為什麼要談到 domain 一定有討論 bounded context 呢 ?

因為一個名詞在不同地方,意思換了,那個『 地方 』就是個『 Bounded Context 』

假設當一個用戶在網頁上看到一個產品 product,然後下訂單『 裡面有該產品 』,最後會在將這個『 產品 」運送給用戶,所以這時 bounded context 事實上有三個 :

  • 網頁上看到『 產品 』
  • 訂單內的『 產品 』
  • 運送給用戶的 『 產品 』

一個『 product 』 在不同的情境下,會有不同的意思,也代表有不同的狀態變化,如果都它將做成同一個,你的產品裡面會存了一堆需符合所有的 bounded context 的狀態。

這裡簡單做個總結 :

一個詞例如 product 是模糊不清的定義,只有在『 Bounded Context 』下才能得到完整的定義

範例如果沒有 Bounded Context 會怎麼樣呢 ?

假設我們有一個 Product 模型 ,然後他一開始有以下的欄位 :

class Product{
  id: string
  title: string
  category: string
  describption: string
}

然後由於它是個產品,所以可以給人買,所以又需要『 購買 』的一些欄位。

class Product{
  id: string
  title: string
  category: string
  describption: string,
  // 購買情境
  price: number
  discount: number
}

接下來因為它是實體產品,還需要加上『 庫存 』相關的欄位。

class Product{  
  id: string
  title: string
  category: string
  describption: string,
  // 購買情境所需
  price: number
  discount: number
  // 庫存情境所需
  qunatity: string
  location: string ( 庫存在那 )
  supplier: string ( 產品供應商 )
}

然後最後還需要『 運輸 』相關的欄位。

class Product{  
  id: string
  title: string
  category: string
  describption: string,
  // 購買情境所需
  price: number
  discount: number
  // 庫存情境所需
  qunatity: string
  location: string
  supplier: string
  // 運輸相關所需
  taxable: string
  shipmment: string
}

到最後你就會得到一個包山包海,要切也不知道如何切的東西,而如果事實就知道 Bounded Context 那就可以分了。

關係 Context Map

目的為從流程上探討,Context 間交互關係與交互的重點。

這個地方我建議直接看這篇文章,我覺得超棒的。

戰略設計:來聊聊 Bounded Context 的世間情 -- Context Mapping

參考資料


上一篇
30-24 之從集中式架構到微服務的難點 - DDD 的誕生
下一篇
30-26 之 DDD 戰略設計 2 - 實作方法之 Event Storm
系列文
馬克的軟體架構小筆記29

尚未有邦友留言

立即登入留言