聊聊微服務和DDD

微服務這個詞在軟體行業可以說火的不能再火了，儘管仍然有很多反對和質疑的聲音，但看到各種微服務的成功案例，尤其是大家耳熟能詳的大公司的案例，越來越多的人開始相信和追捧這一架構，奉為神器。搞得好像沒用過微服務都不好意思說自己是做軟體的。跟著火起來的還有DDD，學名領域驅動設計。大家注意到沒有，《領域驅動設計——軟體核心複雜性應對之道》是EricEvans在2003年就出版的書。那麼，十多年前的這一「學說」是如何與近幾年火熱的微服務聯繫起來的呢？

一、微服務

我們先來看看微服務，自微服務誕生以來，就憑藉著技術異構、彈性易擴展、簡化部署等優勢獲得廣泛的關注。然而，如何劃分微服務，成為開發者們首先面對的難題。由於微服務被提出時就沒有良好的理論支撐如何合理的劃分服務邊界，因此，微服務該有多「微」本身就是個爭議話題。服務大了不夠靈活，小了太過複雜；要松耦合也要有良好的協作；要職責內聚也要靈活擴展。難！想聽聽大家是怎麼做的？誰會把核心的業務攤在桌面上來講？看來沒個方法還真不行。

二、領域驅動設計

再來說說領域驅動設計。2003年《領域驅動設計》就出版發行，要說這些年來它一直不溫不火是什麼原因？個人理解，學習曲線有點陡！

先讓我們了解下DDD。DDD可以看作是一種軟體設計方法，它發展了敏捷，需要軟體開發中的各種角色無障礙溝通，緊密協作；它倡導演進式設計，通過迭代重構逐漸獲得領域模型；領域模型區別於分裂的分析模型和實現模型，是分析設計和實現的統一模型，即代碼與設計（模型）保持一致。要做到這一點，DDD把界面交互、基礎設施、調度框架等與領域無關的實現剝離出去，以保持領域層代碼與模型保持高度一致。很顯然，領域模型成為軟體開發的核心，所以稱作領域驅動設計。

要進一步了解領域模型，我們得介紹介紹下面這些概念

• 通用語言（UL，Ubiquitous Language）

通用語言是項目團隊對系統所解決領域問題的一致性認知，它包括領域術語、設計文檔、代碼和團隊內能夠達成一致的一切系統描述。

• 限界上下文（BC， Bounded Context）

我們都知道，在面向對象開發中，對領域概念的理解是我們抽象建模的基礎。而相同名字的領域概念往往代表的並不一定是完全相同的含義。舉個例子，對於編輯而言，「書」關注的是題目、章節、內容；對出版而言，「書」關注的是作者、版權、第幾版、幾次印刷、紙張；對於發行而言，「書」關注的是單冊還是成套、精裝還是簡版、售價……對於這些概念的不同方面，往往在設計實現上，我們要將其拆分。限界上下文就是這些概念的邊界，在一個BC中，概念是唯一和一致的。限界上下文同時也是職責（業務能力）的邊界，拆分了限界上下文，也就分離了關注點。每個限界上寫文內都會包含一個領域模型。

• 領域模型

領域模型中，包含以下類別的元素： Entity、ValueObject、Aggregate、Service、Factory、Repository。其中的聚合是DDD的核心概念，聚合是一組相關對象的集合。一個限界上下文可能包含一個或多個聚合。通過對聚合的操作來保持聚合內對象的事務一致性。後來，DDD中又拓展出了DomainEvent，用於協調聚合之間和限界上下文之間的最終一致性問題。

三、領域驅動設計和微服務

「分離關注點」、「事務一致性」、「最終一致性」是不是聽著耳熟，這些設計方法的思想與微服務設計不謀而合。人們發現，DDD可以彌補微服務的理論不足：服務最大不要大過一個BC，否則服務內會存在有歧義的領域；服務最小不要小過一個聚合，否則會引入分散式事務的複雜度；服務間最好通過DomainEvent來進行交互，這樣可以讓服務保持松耦合；六邊形架構（DDD分層架構的演進）協助微服務架構快速演進……微服務和DDD的結合，讓微服務架構看起來似乎更加穩健了！