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

13th鐵人賽

馬克

2021-10-10 23:30:08

1341 瀏覽

分享至

接下來我們將要開始重 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
}