幾年前我在前前一家公司任職Architect的時候，開始開啟了我對大型系統架構設計的起點，當時跟我的leader 請教關於 系統之間的互動的設計概念，聊起了發展史。

通常一家持續發展中的企業，他的IT相關系統的建構面貌也幾乎都跟他的企業發展面貌相近，在不同的時間點常常都是一小塊一小塊的被長出來，也因此常常都是彼此獨立的silo並賦予它所被期待的目標。

有時候，組織之間的互動關係正如同系統運作的縮影

然，逐步添增進入到企業內的系統，勢必都需要與其他不同的系統進行溝通，從以前到現在的系統間的溝通(整合)模式有了以下幾種發展演進：

1. 檔案 — 透過指定的存取檔案路徑位置，讓溝通的系統之間透過檔案存取的鎖的輪流掌握，進行資料的更新與獲取。

2. 資料庫 — 有了資料庫以後，把資料庫作為跨系統間資料狀態變化的監控與獲取一時間成了顯學，不管三七二十一，反正我就是把存取的責任從系統卸載，不管是跨Schema 的授權存取，還是跨db之間的db-link 綁定僅讀權限的控制，也都成功地度過了好一段時間。

3. 服務層的API — 陸續大家意識到了，直接暴露資料庫存取層帶來了很多隱憂，表結構產生變化時各個存取端都要一直跟著改動，於是產生了封裝單一業務標的的念頭，只是這API設計的粒度粗細一直也還沒有很好的萬用策略。有人主張從終端使用的角度來設計API ，有人主張從Domain Object 肩負的責任出發，更甚者是兼具兩者，透過組裝的方式把各個Domain Object提供的API 給串接呼叫，提供成為用戶端使用的API。

4. 訊息模式 — 時間走到了ESB/SOA的年代，開始各種廠商大力倡導，透過消息隊列(Message Queue)的方式為系統間的溝通進行分解，由於跨系統間的互動，除了一般業務應用標的用途，也常常伴隨著資料格式的翻譯解釋，此外在實務上的跨平台間的消息溝通也有著通訊協定的包裝與轉換的處理，ESB/SOA可還真活了很長一段時間。

軟體開發的本質其實就是一種對於真實世界的訊息互動的縮影

Reactive Messaging，強調的就是回歸到真實世界的訊息互動的縮影的方式，每一個或多個參與在同一個事件的互動者(元素/系統)，都會關心著他們想知道的話題事件何時被發生，以及事情發生了以後要怎麼因應，當然，若遇到了處理不了的部分可以怎麼樣找到適當的協助方式。

像這樣典型的事件驅動，訊息溝通模式，要回歸到偶像Eric Evans在2003年發表的 Domain Driven Design，在DDD的思維模式下，主張要從Problem Domain出發，確立你要解決的問題的邊界，從而找出:

1. Context

2. Domain

3. Model

4. Ubiquitous Language

快速基本理解DDD，可以看這邊，實際上DDD很深無法一下子看完的…

Domain model 找出來以後，大家開始思考這樣的跨領域之間的訊息交互模式該是什麼樣的方式，2005年另一個偶像Martin Fowler 基於當時對於DDD的理解認知，提出了CQRS 與 Event Sourcing 的設計樣式作為實踐DDD的參考，尤其Event Sourcing樣式充分的支撐了DDD 的訊息跨domain的傳遞模式。

DDD強調，所有的問題本質，都該回歸到以Ubiquitous Language 作為溝通的基礎，把軟體實踐的設計重心都放在Domain Model上，對於當前你所使用的任何技術實踐手段，都應該是屬於偏於外圍的/基底的，隨時都可被拋棄與置換的，所以Eric Evans 也提出了他認為一個理想的系統設計架構原型

我記得在web 興起的那個年代，各家大廠開始紛紛從 Client-Server 轉往 WWW 的系統設計，每一家廠商都推出了符合於自有產品/設備/軟體框架的最有力的推廣話術，各種基於新的Web Design 的pattern 橫空出世，最著名經典的 Java EE 系列的戰爭 → To apply EJB or not !

我印象中我以前也乖乖的K過 Core Java EE Pattern，還跟著他唸了兩個版本(基於不同時期的Java EE version稍有變形)。

人真的很容易被洗腦，我自己也不例外，在面對商用系統與強大的網路資訊傳遞過程中，決大部分的開發者的系統設計風格，都直接的與框架靠攏對齊，從而很自然的衍生出：

每個系統都要有個Service !

每個系統都要有個Facade !

每個系統都要有個Controller!

每個系統都要有個Repository!

更甚者，你幾乎可以在各大知名的框架工具的官方網站上，直接大咧咧地告訴你 Best Project structure convention

人使物，但不要役於物~

從套用這些框架的角度去看，再去回推對照比對Eric Evans 所提的Port And adapters 架構，是不是有種完全相反的感覺?

再回想一下剛開始接觸程式設計以及物件導向語言的時候，我們都知道物件的組成是涵蓋了屬性與行為，但怎麼真的工作以後卻發現好像寫出來的代碼都跟一開始的理解差很多，有一堆的DTO，有一堆的不知道要幹嘛被工具gen出來的物件!

而且領域物件本身是有狀態的，但WEB 類型的系統設計卻都是無狀態的

領域物件被我們設計出來之後，他的狀態始終都只是被落地到資料庫去(以交易型系統的設計來看，幾乎都是如此) ~

至此，重新回歸初心，再想想你年輕時第一次接觸Object的時候的那個擬人化的學習描述方式 → 物件有動作，有責任，有資料，有代表的意義 !!

Reactive Messaging with Actor Model，正是要以此為起點，用這樣基於DDD的基本思維模式來進行系統設計

持有狀態，事件驅動，關注變化 !