【注】本文譯自：
https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture

這篇文章是關(guān)于軟件設(shè)計的選擇。特別是大型系統(tǒng)，這些系統(tǒng)可能會以服務(wù)端點的形式分為多個可部署的對象。我不會特別談?wù)摲?wù)端點設(shè)計，但是我想討論創(chuàng)建多個服務(wù)應(yīng)用的構(gòu)思階段。

當(dāng)我們面對復(fù)雜的問題時，我們通常試圖理解復(fù)雜的單個部分。通過分解問題，我們將其變成為更易于理解和管理的部分。

正如在許多產(chǎn)品/項目管理周期中所描述的，對于現(xiàn)實生活中的問題，這通常是由本能驅(qū)動的。 我們不會使用公式來了解去一個需要簽證的國家需要做什么。我們知道我們需要簽證才能旅行，我們慢慢掌握需要的文件文件，需要填寫哪些表格以及如何填寫這些表格。當(dāng)我們執(zhí)行其中一個步驟時，我們不會將流程的所有細(xì)節(jié)都牢記在心，而只是要做手頭的任務(wù)。這與要完成的任務(wù)的大小有關(guān)。潛在的真實標(biāo)準(zhǔn)是關(guān)于時間或進(jìn)度、我們的執(zhí)行力、我們的認(rèn)知能力及其與任務(wù)熟悉程度的關(guān)系，甚至可能是執(zhí)行這些任務(wù)的物理位置（ 領(lǐng)事館與 Photoshop 等）。

在軟件開發(fā)領(lǐng)域并沒有什么不同。多年來，瀑布式的配方已被應(yīng)用到軟件開發(fā)過程中，最終，主要是基于啟發(fā)式和基于經(jīng)驗的評估技術(shù)（計劃撲克<Planning Poker>、T - 恤尺寸<T-shirt size>）和敏捷過程。在現(xiàn)實生活中，我們試著不去詳述整個過程，而是通過觀察我們的最新表現(xiàn)來嘗試和理解整個旅程。

同樣適用于我們針對問題建模的軟件。我們開始將它們分解為不同的應(yīng)用的是方便管理單個應(yīng)用，以更少的依賴關(guān)系更快地開發(fā)和部署，最后帶來更多的技術(shù)選擇自由。我們意識到，我們無法制定出適合所有人的完整流程。我們著眼于各個部分，并認(rèn)識到我們在設(shè)計模式或技術(shù)方面的集體經(jīng)驗，并嘗試應(yīng)用其中最好的選擇。

理解和解決復(fù)雜性的一個有趣的軟件設(shè)計技術(shù)是領(lǐng)域驅(qū)動設(shè)計（DDD）。領(lǐng)域驅(qū)動設(shè)計提倡基于與我們的用例相關(guān)的業(yè)務(wù)現(xiàn)實進(jìn)行建模。由于 DDD 方法現(xiàn)在已經(jīng)過時，而且宣傳水平正在下降，我們許多人都忘記了 DDD 方法確實有助于理解手頭的問題，并朝著對解決方案的普遍理解來設(shè)計軟件。在構(gòu)建應(yīng)用DDD 會以域和子域的形式討論的問題。它將問題的獨立步驟/領(lǐng)域描述為邊界上下文，強(qiáng)調(diào)使用一種通用語言來討論這些，并添加了許多技術(shù)概念，如實體、值對象和聚合根規(guī)則以支持實現(xiàn)。有時，這些技術(shù)規(guī)則被視為是實施 DDD 的硬障礙，但最終，人們往往會忘記重要的部分是根據(jù)業(yè)務(wù)問題組織代碼工件，并使用與（1）相同的通用語言。

設(shè)計為服務(wù)應(yīng)用的邊界上下文

我想談?wù)摰募軜?gòu)風(fēng)格與微服務(wù)非常相似。它是關(guān)于將單體應(yīng)用分離為多個獨立的服務(wù)應(yīng)用，或者從一開始就在邊界上下文（DDD概念）的幫助下單獨開發(fā)它們。

有許多資源都強(qiáng)調(diào)了微服務(wù)敘述中更細(xì)粒度的服務(wù)的優(yōu)點。越來越多的文章、博客和其他內(nèi)容是關(guān)于陷阱和在向細(xì)粒度服務(wù)過渡之前或過渡期間應(yīng)該擁有的安全網(wǎng)的。我將盡量不重復(fù)微服務(wù)或其他支持元素的好處，這些是遷移到這樣的體系結(jié)構(gòu)中所需要。我不想強(qiáng)調(diào)結(jié)果服務(wù)的“小型”性質(zhì)，而是想強(qiáng)調(diào)如何通過應(yīng)用領(lǐng)域驅(qū)動的設(shè)計概念來更好地分離這些服務(wù)。

讓我們使用一個真實的示例來實現(xiàn)我們的想法-借記卡/信用卡獲取域。這個領(lǐng)域可以（不幸的是，很多時候都是這樣）作為一組單體應(yīng)用來實現(xiàn)。我們擁有多個應(yīng)用的唯一原因是由于不同的應(yīng)用中的存在嚴(yán)格的技術(shù)限制（例如希望執(zhí)行批處理）。

我所看到的大多數(shù)成功的架構(gòu)都認(rèn)識到，通過數(shù)據(jù)庫進(jìn)行集成是一種糟糕的實踐，因為它使技術(shù)應(yīng)用和業(yè)務(wù)職責(zé)之間的界限變得模糊，使業(yè)務(wù)邏輯泄漏到數(shù)據(jù)庫中,并通過添加更多的應(yīng)用服務(wù)器來阻止水平擴(kuò)展。因此，以單體應(yīng)用的的服務(wù)集成的形式發(fā)展到更好的架構(gòu)。

現(xiàn)在，應(yīng)用之間的界限更加清晰了。但是，您可以看到，仍然存在隱藏的數(shù)據(jù)庫交互，這一次是在各個應(yīng)用內(nèi)部發(fā)生的。我稱它們?yōu)殡[藏的，因為通常一開始它們通常很難被注意到。隨著時間的流逝，代碼的糾纏將使原先分離的業(yè)務(wù)流程人為地關(guān)聯(lián)起來，并在業(yè)務(wù)開發(fā)中引入更多的摩擦，因為這種共置托管需要聯(lián)合部署單獨的功能，這可能會減慢速度。

如果您幸運(yùn)地有一個領(lǐng)域模型來指導(dǎo)的話，則領(lǐng)域建?？蓭椭R別和分離復(fù)雜的實現(xiàn)。如果您還沒有現(xiàn)有應(yīng)用的域模型（在大多數(shù)情況下通常是這樣），則無需遍歷代碼以了解不同的職責(zé)，而是構(gòu)建域模型并將功能映射到手邊的應(yīng)用可能是一個更好的方法。這既能節(jié)省時間，又能避免被細(xì)節(jié)淹沒的風(fēng)險。此外，如果業(yè)務(wù)與開發(fā)團(tuán)隊之間存在差距（這可能是域模型最初不存在的主要原因），那么討論域模型并映射到現(xiàn)有應(yīng)用的功能將有助于縮小這一差距。

我們設(shè)計演進(jìn)的下一步是將域邊界分離反映到我們的架構(gòu)以及邊界上下文中。一個域具有多個邊界上下文意味著在同一域中可以有多個服務(wù)應(yīng)用運(yùn)行。有了適當(dāng)?shù)挠蚰Ｐ?，潛在的分離點就更可見了，這使我們可以從潛在的更細(xì)粒度的應(yīng)用中受益（諸如單獨發(fā)行和版本控制的好處，具有更多功能驅(qū)動的純服務(wù)端點的潛力等，其中大多數(shù)已經(jīng)在微服務(wù)文章中進(jìn)行了討論）。盡管許多微服務(wù)討論都圍繞技術(shù)不可知論和開發(fā)規(guī)范（避免/破壞整體），但對于我們大多數(shù)人所從事的應(yīng)用而言，非常有價值的一項是領(lǐng)域和設(shè)計方面。一旦過渡到微服務(wù)架構(gòu)（借助域模型），DDD 和更細(xì)粒度的服務(wù)便可以協(xié)同工作、相互支持。

這還將為團(tuán)隊提供一定程度的獨立性，更完善的服務(wù)功能以及更分離的交互，如許多微服務(wù)文章所述。

同樣，從我們的示例信用卡付款獲取域中可以看出，這并不是我們的服務(wù)可以做到的最細(xì)粒度的分離。相反，這是在我們的領(lǐng)域知識所指導(dǎo)下最有意義的分離。重點不是規(guī)模，而是業(yè)務(wù)能力。我相信這是“正確的 SOA”，正如許多圈子所說的那樣。