能顯示業務目標的DDD微服務架構圖 -Aleix

banq發表於2022-12-07
微服務架構

從我職業生涯的一開始，我就一直在分析和繪製架構圖。
他們中的大多數人關注正在使用的技術以及它們如何相互通訊。他們中很少有共同的商業目的。
您有多少次需要在檢視圖表時與某人交談以詢問該服務的作用？那一個呢？
在這篇文章中，我分享了一個顯示元素業務目的的架構圖。

在下圖中，我展示了您今天在公司中可能擁有的合理圖表。
我敢肯定，您將擁有更多人類可讀的名稱，而不是將名稱作為服務 A的框，而且，如果您足夠幸運，這些名稱將是與業務相關的名稱，例如使用者、賬單、帳戶，信用卡，……

能顯示業務目標的DDD微服務架構圖 -Aleix

看著這張圖，你能說：

  • 哪個服務是核心的，哪個是支援性的？
  • 每項服務是什麼？
  • 為什麼他們需要互相交談？
  • 它們是同步的還是非同步的？
  • 您需要了解每項服務之間使用的每項技術。


這張圖著重於兩件事：
  • 資訊流。
  • 支援資訊流的技術。

為什麼我們將重點放在正在使用的技術上，而不是放在它們解決什麼問題上？

讓我們從為服務新增意義開始，這樣才能表達其能解決什麼問題
領域驅動設計分享了我們擁有三種型別的領域：

  • 核心領域：這是你在一個單一的、定義良好的領域模型上進行戰略投資的地方，投入大量資源在明確的限界上下文中精心打造你的通用語言。
  • 支援子域：這種建模情況需要定製開發，因為不存在現成的解決方案。
  • 通用子域：這種解決方案可能是現成的。你不想在這裡進行那種投資。

在圖中注意到每個服務的域型別不是很酷嗎？

能顯示業務目標的DDD微服務架構圖 -Aleix
​

突然之間，我們可以看到哪些服務比其他服務更重要。這可能比其他人發展得更快。
但是他們做什麼呢？他們的用例是什麼？他們為什麼互相呼叫？
我們需要有足夠的資訊來了解他們的用例。

當我檢視圖表時，我想知道：

  • 哪些是主要實體。
  • 哪些是主要用例。
  • 服務如何與它們互動。同步或非同步。
  • 它們發出哪些事件，哪些服務監聽它們。

要將此資訊新增到圖中，我們可以使用 4 個主要框：
  • API/入口點。
  • 用例。
  • 實體。
  • 事件。

他們如何溝通可以用實線（同步呼叫）或虛線（非同步所有）箭頭標記。

能顯示業務目標的DDD微服務架構圖 -Aleix
​


讓我們看看我們的圖表如何根據這些資訊發展。

能顯示業務目標的DDD微服務架構圖 -Aleix
​


現在，我們可以檢視圖表並瞭解每個服務的職責和業務目的。

這是我使用的 excalidraw。

  • 該圖需要顯示高階概述。
  • 如果我們有太多的資訊，它就會由於資訊溢位而失去目的。

  • 我知道這張圖不適合色盲。請在圖表中新增註釋，以便對您的同事更具包容性。

能顯示業務目標的DDD微服務架構圖 -Aleix
​
 

相關文章