到底什麼是微服務？其實就是DDD領域服務

著名DDD社群意見領袖Nick Tune撰文認為微服務就是領域服務，建議使用領域服務替代微服務，banq贊成這種做法，在我的DDD書籍中已經將這兩個概念混為一談，當然他們還是有細微差別，比如微服務可能有關技術或應用方面功能例如增刪改查CRUD可以在微服務中實現，但是不是好的領域服務功能，因為CRUD是一種資料庫操作概念，是業務邏輯相當簡單甚至為零的領域服務功能，當然它也對應API的POST/PUT等資源操作，從CRUD角度能夠學習理解微服務 領域服務和領域API. 下面是ntcoding原文翻譯，原文點選標題。

微服務時代到來對於軟體架構來說是一個好時機。我記得當年如果你有想設計多個資料庫的想法時，會立即被當時人們處以死刑。但是，對微服務的過度關注已經削弱了微服務的真正好處，即提高服務質量和開發速度。

在過去的幾年中，我看到人們將微服務稱為領域服務。我已經從這種小型重組中看到了好處，我現在建議不要使用單詞微服務microservice，而是使用領域服務Domain Service。

對微服務的批評很多，而且還有很多恐怖的故事。但是，我不希望對微服務進行口口相傳，以大肆宣傳一個新的流行語。對於微服務運動取得的成就，我將不勝感激，這些想法應繼續得到應用。

任何可以使用的東西都可能被濫用。所有的好主意和概念都可能以錯誤的方式應用。我們的工作是在行之有效的基礎上，改進行之有效的方法。我已經看到將微服務框架化為領域服務保留了鬆散耦合的優勢，並消除了對微服務的痴迷。

微服務也有很多負擔，通常會抵消有關其優點的討論。這主要是由於應用不當，人們指責微服務，而不是有關概念本身的任何事情。

什麼是領域服務或領域API？

領域服務建立在微服務的基本定義之上：它是一個鬆散耦合的，可獨立部署的軟體體系結構元素，由一個團隊擁有。

重要的是，領域服務的重點在於它代表了一個專業領域，企業在該領域中開發能力以向客戶交付產品和價值主張。

領域是企業邏輯體系結構的一部分。組織構建的產品可以為客戶群提供價值主張。產品由邏輯上存在於業務領域中的功能提供支援。

業務領域通常是多個團隊在其中開展業務開發的領域。一個業務域可以細分為多個子域。領域服務的建議邊界是子域，因為對於單個團隊來說，邊界不應太大。

業務域通常是由多個子域組成的大部分業務區域。

舉一個具體的例子，這是Uber的定義以及他們業務中的一些真例項子：

Uber領域代表與功能的邏輯分組相關聯的一個或多個微服務的集合。設計域時常見的問題是“域應該有多大？”

我們在此不提供任何指導。有些域可以包含數十個服務，有些域只能包含一個服務。重要的任務是仔細考慮每個集合的邏輯作用。例如，我們的地圖搜尋服務構成一個域，票價服務是一個域，匹配平臺（匹配的騎手和駕駛員）是一個域。這些也不總是遵循公司的組織結構。

Uber Maps地圖組織本身又分為三個域，在三個不同的閘道器後面有80個微服務。

Uber不使用術語“子域”，他們更喜歡使用微服務。實際上，它們在域中的每個服務都代表該域的一部分，我稱之為子域，但是您可以決定將其命名為不同的東西。

新構架，新問題

毫無疑問，微服務已證明命名很重要。我認為我們所有人都參與了許多關於“微服務應該有多大？”的辯論，人們拿起材料告訴我們微服務應該是100行或更少的程式碼行。即使在2021年，作為顧問和培訓師，這仍然是我一生中經常遇到的問題。

因此，更改名稱（將微服務更名為領域服務）將產生重大影響。有可能會失去當前的某些優勢並可能引入新的問題。我看到的新問題是，現在人們在問“什麼是領域？”，“我們如何找到領域邊界？”，“我們如何命名領域API？”。但是，這是一件好事。這些是我們希望人們提出的問題，因為它們與理解業務以及使體系結構的設計與業務保持一致有關。

其他缺點肯定會出現。每個想法都可能被濫用和錯誤應用，尤其是好主意。我絕不暗示這是架構的終結，但我已經看到了足夠的證據表明這是向前邁出的一大步。

改變敘事方式可以提高利益相關者的參與度，在使用術語“領域服務”或“領域API”時，我發現產品所有者/經理，業務分析人員以及組織中的其他同事更加感興趣，他們更加註重業務，技術含量較低。

我的感覺是，微服務被非工程師和非架構師視為純粹的技術概念。我通常不會看到那些使用微服務一詞或參與有關微服務的對話的人。

在談論領域服務/ API時，我看到那些人更舒適地使用這些術語，並進行了相對詳細的對話，涉及定義領域服務的邊界，業務規則如何在域服務中而不是在BFF中存在，以及對幫助命名的真實渴望。包括領域服務，API端點及其代表的概念。

不捆綁任何方法論或框架

品牌重塑嘗試通常用於宣傳新的頭或使新的思想領袖建立自己的形象。這不是嘗試這樣做。實際上，將微服務重新定義為領域服務並不依賴於任何想法或框架。這更多是為了改善協作和設計文化。

去年，Uber在Uber上釋出了面向領域的微服務，向我們展示了微服務的發展，使其更加註重領域。但是您不需要遵循他們的方法。域驅動設計已經存在了將近20年，但是您無需閱讀，學習或應用任何有關域驅動設計的知識，就可以對軟體體系結構採用更加面向領域的方法。

無需重寫系統

好的微服務架構（MSA）已經是好的面向領域的架構（DOA）。無需重新設計和重寫您的系統即可與最新的體系結構流行語相容。

如果您確實檢視了微服務架構，並且覺得它不是非常面向領域的，那麼這就是考慮重新設計的一個很好的理由，因為您正在改進架構的設計，而不是嘗試與流行語相容。

從現在開始…

不是我開始呼叫微服務域服務或域API的趨勢。在過去的幾年中，我已經看到它在一些大客戶中有機地發生了。但是，我覺得以業務為中心的框架會導致更好的對話和更好的設計架構，從現在開始，我將使用術語域服務和域API。希望取得積極成果的趨勢將繼續下去

DDD+微服務大型案例：Uber如何從複雜的RPC微服務轉向面向業務領域的微服務架構DOMA？ -優步工程部落格