DDD與微服務是可以相通的，其關鍵在于Bounded Context。
分布式系統的定義
在談論這個之前，我們需要就什麼是分布式系統達成一緻。在我看來，判斷一個系統是否是分布式的，其标準是看系統中是否存在跨程序通信。是程序決定了協作與通信的方式，進而引申出兩種具有本質差別的程式設計模型：
程序内程式設計模型
跨程序程式設計模型
它們之間的差別在于元件之間的調用方式。程序内的元件調用是非常簡單的，就Java而言，各個駐留于同一個JVM的對象與變量都放在堆記憶體或者棧記憶體中，對象的調用（包括方法的調用）就是一種記憶體的尋址。Java語言通過new關鍵字建立執行個體，進而獲得該執行個體的指針，以便于對該執行個體的屬性與方法進行調用。
跨程序元件之間的調用方式與程序内調用有着本質的。雖然跨程序通信機制存在各種不同的實作，但它們要考量的因素都是相同的，需要考慮：
程序間的通信協定
如何尋址
消息的序列化與反序列化
除此之外，在資源管理、事務一緻性以及部署方面，都會因為跨程序通信的原因而産生巨大的差别。
顯然，跨程序通信固有的複雜度帶來了程式設計模型的改變，但它能夠更加有效地利用硬體資源，卻是分布式系統的主要目标。是以，在IT發展的目前曆史背景下，我們将程序作為邊界來定義分布式系統是非常有意義的。
說明：不同的語言平台，程序的概念有細微差别，通信機制自然也有所不同。Java程序等同于作業系統的程序，但Erlang與Go的程序概念則不相同，要更加輕量級。
跨程序元件之間的調用方式其實是對通信機制的一種抽象，它其實又包含了：
程序間通信機制（如共享記憶體、管道、Socket）
結構化通信機制（如RPC）
中間件通信機制（分布式對象如CORBA、元件中間件如EJB、消息中間件、面向服務與REST）
讨論C4模型的Container
Simon Brown提出了自己的C4模型，如下圖所示：
我們對Container的劃分，可以将程序作為劃分的邊界，即我認為的“實體邊界”。是以Container在架構中除了可以作為邏輯視圖的組成元素之外，也可以視為實體視圖的一部分。
無獨有偶，Alistair Cockburn提出的六邊形架構（又名port-adapter模式）在邊界含義上與Container是與之呼應的。下圖中外部六邊形的邊界就是一個實體邊界，按照之前的分析，我們可以将其視為程序邊界。
微服務與Bounded Context
微服務作為一個可以獨立部署的微小服務，天生就是一個在實體上隔離的自治服務。從實體視圖的角度看，一個微服務就是C4模型中的Container，也就是六邊形架構中的六邊形。如果我們将六邊形架構與DDD的Bounded Context對應起來，那麼就可以引入DDD的戰略設計來劃分服務邊界，進而幫助我們進行微服務設計了。
一個典型的Bounded Context，可以具有自己的領域模型，通路專有的資料庫，且可以引入“依賴注入”來滿足Uncle Bob所謂的Clean Architecture思想。下圖所示的Bounded Context的架構，不正是可以表現為一個微服務嗎？
Context Map對微服務的闡釋
思考DDD中的Bounded Context，可以重點把握以下兩點：
Bounded Context與Domain之間的關系
Context Map
倘若我們認為Bounded Context與Domain之間存在對應關系，就說明可以從業務架構的層面來設計微服務。通過用例、通用語言或者其他手段，都可以幫助我們識别Bounded Context，進而得到相對合理的服務邊界。
若要判斷微服務的設計是否合理，則可以通過DDD的Context Map進一步驗證和判别Bounded Context的劃分，并理清楚它們之間的關系。
Eric Evans在DDD一書中列出了九種Context Map，基本上可以歸類為：
團隊之間的協作方式
程序之間的內建方式
為什麼說Bounded Context之間的關系可以了解為是團隊之間的協作方式呢？理論根據來自康威定律，即：
設計一個系統（此處泛指更廣泛的系統，而不僅僅是資訊系統）的任何組織都必然會産生一個其結構是該組織通信結構副本的設計。
一個Bounded Context可能會映射到一個開發團隊，是以讨論Bounded Context之間的關系，也可以視為是讨論團隊之間的關系。至于程序之間的內建方式，無論是引入ACL（防腐層）還是OHS（開放主機服務），目的都是在實作程序間通信的同時，更好地做到Bounded Context之間的松散耦合。以微服務觀之，就是要滿足服務邊界足夠的自治性。
故而當DDD遇到微服務，其實有許多玄妙的相似之處值得深究。它們之間或許可以碰撞出感情的火花，也未可知呢。
原文釋出時間為：2017-12-22
本文作者：張逸