論領域驅動設計在微服務開發中的作用

在近期于德國柏林舉辦的 microXchg大會 上，來自innoQ的 Michael Pl?d 在一場 演講 中談到了如何在開發 微服務 的過程中使用 領域驅動設計 （DDD）的話題。在他看來，微服務與DDD之間的聯系不僅僅只限于 界限上下文 （Bounded Context）的概念而已，雖然界限上下文確實是一種可用于定義微服務粒度的基礎工具，但其他一些概念也同樣重要。相應地，DDD也并非只單純地代表實體、值對象與repository等概念而已。

Pl?d是 innoQ 的首席顧問。他相信，在創建微服務的過程中，DDD可以在以下4個主要領域發揮作用：

• 戰略設計 —— 這一階段的主要工作就是界限上下文的設計，但 上下文圖 （Context Map）與其他模式也同樣十分重要。
• 內部構建塊 —— 在設計一個界限上下文的內部結構時將用到DDD中的多種戰術模式，例如實體、聚合以及repository。
• 大比例結構 （Large-scale Structure），通過有序演化與職責層模式創建結構。
• 精煉 —— 通過精煉方法，從一個已經成熟的系統中 提煉出一個核心領域 。

任何一個具有高復雜度的業務領域都由一個或多個界限上下文組成，每個上下文負責領域中的一部分內容。每個界限上下文都包含用于描述領域的模型，同時也定義了這些模型所代表的意義的邊界。以一個客戶對象為例，每個界限上下文都是按照獨有的模型與視角來定義這個客戶對象的。在Pl?d看來，這一特性對于開發獨立的微服務能夠起到重要的促進作用。

上下文圖描述了系統中的所有界限上下文，以及他們之間的相互關聯及上下文之間的契約。Pl?d相信，對于已有打算進行微服務轉型的組織來說，上下文圖將帶來極大的便利。不僅如此，上下文圖還能夠作為今后的轉型過程中的一個良好的起點。以下是界限上下文之間常見的關系模式：

• 共享內核模式 （Shared Kernel） —— 它表示兩個上下文或模型之間共享某個領域的一個子集，包括代碼在內。Pl?d提示，這種模式將增加系統的依賴。
• 客戶 / 供應商模式 （Customer / Supplier） —— 某個上下文將扮演客戶的角色，它將從另一個扮演供應商角色的上下文中請求特性。
• 防崩潰層 （Anticorruption layer， ACL ）—— 某個客戶端將利用轉換器（translator），將其自身的模型與其他模型進行隔離。在將系統轉型為微服務或 自包含系統 （Self-Contained，SCS）架構時，這是一種非常有趣的選擇，ACL將表現為一個系統的護罩，以抵御來自外部的侵擾。

在DDD的各種內部構建塊中，Pl?d特別提到了聚合的重要性。聚合是由多個領域對象構成的一個邏輯組，其中的對象將作為一個整體進行處理。聚合中的某個實體將成為聚合根，它負責接收所有外部請求，并負責整個聚合的生命周期。

對于僵硬的架構或是過于復雜的系統來說，可以選擇創建一個跨界限上下文的大比例結構，讓這個結構隨著對于高層次概念的理解不斷加深而逐漸進化。Pl?d表示，這一點也是微服務架構的核心思想之一，微服務的設計應當是可以不斷進化的。職責層模式是另一種在界限上下文之內創建一個內部結構的結構模式，其思想是按照職責進行結構的創建，而微服務的結構也可以應用相同的概念進行設計。

在將某個遺留系統轉型至微服務或是自包含系統架構時，精煉方法能夠幫助開發者從一個現有的 一體性系統 中提煉出微服務。首先要辨別并提煉出核心領域，然后再通過迭代方法找出子領域，將其從核心領域中提取出來，最后再進行一些內部的清理與重構工作。P?dl特別強調了為核心領域的業務功能與細節實現文檔化的重要性。如果對于業務功能沒有一個清晰的愿景及深刻的理解，就會增加無法發現最佳的界限上下文的風險。

P?dl在演講的最后回顧了以上概念，并在總結陳述中表示微服務與DDD能夠很好地結合在一起。但他同時也提示，開發者應當具有大局觀，而不是將注意力僅僅放在界限上下文中。

查看英文原文： Using Domain-Driven Design When Creating Microservices