文/滕云
稍微回想一下計算機硬件的工作原理我們便不難發(fā)現(xiàn)，整個計算機的工作過程其實就是一個對事件的處理過程壮锻。當你點擊鼠標岛请、敲擊鍵盤或者插上U盤時秕硝，計算機便以中斷的形式處理各種外部事件沫浆。在軟件開發(fā)領域捷枯，事件驅動架構（Event Driven Architecture滚秩，EDA）早已被開發(fā)者用于各種實踐专执，典型的應用場景比如瀏覽器對用戶輸入的處理、消息機制以及SOA郁油。最近幾年重新進入開發(fā)者視野的響應式編程（Reactive Programming）更是將事件作為該編程模型中的一等公民本股。可見桐腌，“事件”這個概念一直在計算機科學領域中扮演著重要的角色拄显。
認識領域事件
領域事件（Domain Events）是領域驅動設計（Domain Driven Design，DDD）中的一個概念案站，用于捕獲我們所建模的領域中所發(fā)生過的事情躬审。領域事件本身也作為通用語言（Ubiquitous Language）的一部分成為包括領域專家在內的所有項目成員的交流用語。比如蟆盐，在用戶注冊過程中承边，我們可能會說“當用戶注冊成功之后，發(fā)送一封歡迎郵件給客戶石挂〔┲”，此時的“用戶已經(jīng)注冊”便是一個領域事件痹愚。
當然富岳，并不是所有發(fā)生過的事情都可以成為領域事件蛔糯。一個領域事件必須對業(yè)務有價值，有助于形成完整的業(yè)務閉環(huán)窖式，也即一個領域事件將導致進一步的業(yè)務操作蚁飒。舉個咖啡廳建模的例子，當客戶來到前臺時將產生“客戶已到達”的事件萝喘，如果你關注的是客戶接待飒箭，比如需要為客戶預留位置等，那么此時的“客戶已到達”便是一個典型的領域事件蜒灰，因為它將用于觸發(fā)下一步——“預留位置”操作弦蹂；但是如果你建模的是咖啡結賬系統(tǒng)，那么此時的“客戶已到達”便沒有多大存在的必要——你不可能在用戶到達時就立即向客戶要錢對吧强窖，而”客戶已下單“才是對結賬系統(tǒng)有用的事件凸椿。
在微服務（Microservices）架構實踐中，人們大量地借用了DDD中的概念和技術翅溺，比如一個微服務應該對應DDD中的一個限界上下文（Bounded Context）脑漫；在微服務設計中應該首先識別出DDD中的聚合根（Aggregate Root）；還有在微服務之間集成時采用DDD中的防腐層（Anti-Corruption Layer, ACL）咙崎；我們甚至可以說DDD和微服務有著天生的默契优幸。更多有關DDD的內容，請參考筆者的另一篇文章或參考《領域驅動設計》及《實現(xiàn)領域驅動設計》褪猛。
在DDD中有一條原則：一個業(yè)務用例對應一個事務网杆，一個事務對應一個聚合根，也即在一次事務中伊滋，只能對一個聚合根進行操作碳却。但是在實際應用中，我們經(jīng)常發(fā)現(xiàn)一個用例需要修改多個聚合根的情況笑旺，并且不同的聚合根還處于不同的限界上下文中昼浦。比如，當你在電商網(wǎng)站上買了東西之后筒主，你的積分會相應增加关噪。這里的購買行為可能被建模為一個訂單（Order）對象，而積分可以建模成賬戶（Account）對象的某個屬性乌妙，訂單和賬戶均為聚合根使兔，并且分別屬于訂單系統(tǒng)和賬戶系統(tǒng)。顯然冠胯，我們需要在訂單和積分之間維護數(shù)據(jù)一致性火诸，通常的做法是在同一個事務中同時更新兩者，但是這會存在以下問題：
- 違背DDD中"單個事務修改單個聚合根"的設計原則荠察；
- 需要在不同的系統(tǒng)之間采用重量級的分布式事務（Distributed Transactioin置蜀，也叫XA事務或者全局事務）奈搜；
- 在不同系統(tǒng)之間產生強耦合。
通過引入領域事件盯荤，我們可以很好地解決上述問題馋吗。 總的來說，領域事件給我們帶來以下好處：
還是以上面的電商網(wǎng)站為例绍哎，當用戶下單之后，訂單系統(tǒng)將發(fā)出一個“用戶已下單”的領域事件鞋真，并發(fā)布到消息系統(tǒng)中崇堰，此時下單便完成了。賬戶系統(tǒng)訂閱了消息系統(tǒng)中的“用戶已下單”事件涩咖，當事件到達時進行處理海诲，提取事件中的訂單信息，再調用自身的積分引擎（也有可能是另一個微服務）計算積分檩互，最后更新用戶積分特幔。可以看到闸昨，此時的訂單系統(tǒng)在發(fā)送了事件之后蚯斯，整個用例操作便結束了，根本不用關心是誰收到了事件或者對事件做了什么處理零院。事件的消費方可以是賬戶系統(tǒng)溉跃，也可以是任何一個對事件感興趣的第三方村刨，比如物流系統(tǒng)告抄。由此，各個微服務之間的耦合關系便解開了嵌牺。值得注意的一點是打洼，此時各個微服務之間不再是強一致性，而是基于事件的最終一致性逆粹。
事件風暴（Event Storming）
事件風暴是一項團隊活動募疮，旨在通過領域事件識別出聚合根，進而劃分微服務的限界上下文僻弹。在活動中阿浓，團隊先通過頭腦風暴的形式羅列出領域中所有的領域事件，整合之后形成最終的領域事件集合蹋绽，然后對于每一個事件芭毙，標注出導致該事件的命令（Command）筋蓖，再然后為每個事件標注出命令發(fā)起方的角色，命令可以是用戶發(fā)起退敦，也可以是第三方系統(tǒng)調用或者是定時器觸發(fā)等粘咖。最后對事件進行分類整理出聚合根以及限界上下文。事件風暴還有一個額外的好處是可以加深參與人員對領域的認識侈百。需要注意的是瓮下，在事件風暴活動中，領域專家是必須在場的钝域。更多有關事件風暴的內容讽坏，請參考這里。
創(chuàng)建領域事件
領域事件應該回答“什么人什么時候做了什么事情”這樣的問題例证，在實際編碼中震缭，可以考慮采用層超類型(Layer Supertype)來包含事件的某些共有屬性：
public abstract class Event {
private final UUID id;
private final DateTime createdTime;
public Event() {
this.id = UUID.randomUUID();
this.createdTime = new DateTime();
}
}
可以看到，領域事件還包含了ID战虏，但是該ID并不是實體（Entity）層面的ID概念拣宰，而是主要用于事件追溯和日志。另外烦感，由于領域事件描述的是過去發(fā)生的事情巡社，我們應該將領域事件建模成不可變的（Immutable）。從DDD概念上講手趣，領域事件更像一種特殊的值對象（Value Object）晌该。對于上文中提到的咖啡廳例子，創(chuàng)建“客戶已到達”事件如下：
public final class CustomerArrivedEvent extends Event {
private final int customerNumber;
public CustomerArrivedEvent(int customerNumber) {
super();
this.customerNumber = customerNumber;
}
}
在這個CustomerArrivedEvent事件中绿渣，除了繼承自Event的屬性外朝群，還自定義了一個與該事件密切關聯(lián)的業(yè)務屬性——客戶人數(shù)（customerNumber）——這樣后續(xù)操作便可預留相應數(shù)目的座位了。另外中符，我們將所有屬性以及CustomerArrivedEvent本身都聲明成了final姜胖，并且不向外暴露任何可能修改這些屬性的方法，這樣便保證了事件的不變性淀散。
發(fā)布領域事件
在使用領域事件時右莱，我們通常采用“發(fā)布-訂閱”的方式來集成不同的模塊或系統(tǒng)。在單個微服務內部档插，我們可以使用領域事件來集成不同的功能組件慢蜓，比如在上文中提到的“用戶注冊之后向用戶發(fā)送歡迎郵件”的例子中，注冊組件發(fā)出一個事件郭膛，郵件發(fā)送組件接收到該事件后向用戶發(fā)送郵件晨抡。
在微服務內部使用領域事件時，我們不一定非得引入消息中間件（比如ActiveMQ等）。還是以上面的“注冊后發(fā)送歡迎郵件”為例耘柱，注冊行為和發(fā)送郵件行為雖然通過領域事件集成圆雁，但是他們依然發(fā)生在同一個線程中，并且是同步的帆谍。另外需要注意的是伪朽，在限界上下文之內使用領域事件時，我們依然需要遵循“一個事務只更新一個聚合根”的原則汛蝙，違反之往往意味著我們對聚合根的拆分是錯的烈涮。即便確實存在這樣的情況，也應該通過異步的方式（此時需要引入消息中間件）對不同的聚合根采用不同的事務窖剑，此時可以考慮使用后臺任務坚洽。
除了用于微服務的內部，領域事件更多的是被用于集成不同的微服務西土，如上文中的“電商訂單”例子讶舰。
通常，領域事件產生于領域對象中需了，或者更準確的說是產生于聚合根中跳昼。在具體編碼實現(xiàn)時，有多種方式可用于發(fā)布領域事件肋乍。
一種直接的方式是在聚合根中直接調用發(fā)布事件的Service對象鹅颊。以上文中的“電商訂單”為例，當創(chuàng)建訂單時墓造，發(fā)布“訂單已創(chuàng)建”領域事件堪伍。此時可以考慮在訂單對象的構造函數(shù)中發(fā)布事件：
public class Order {
public Order(EventPublisher eventPublisher) {
//create order
//…
eventPublisher.publish(new OrderPlacedEvent());
}
}
注：為了把焦點集中在事件發(fā)布上，我們對Order對象做了簡化觅闽，Order對象本身在實際編碼中不具備參考性帝雇。
可以看到，為了發(fā)布OrderPlacedEvent事件蛉拙，我們需要將Service對象EventPublisher傳入尸闸，這顯然是一種API污染，即Order作為一個領域對象只需要關注和業(yè)務相關的數(shù)據(jù)刘离，而不是諸如EventPublisher這樣的基礎設施對象室叉。另一種方法是由NServiceBus的創(chuàng)始人Udi Dahan提出來的，即在領域對象中通過調用EventPublisher上的靜態(tài)方法發(fā)布領域事件：
public class Order {
public Order() {
//create order
//...
EventPublisher.publish(new OrderPlacedEvent());
}
}
這種方法雖然避免了API污染硫惕，但是這里的publish()靜態(tài)方法將產生副作用，對Order對象的測試帶來了難處野来。此時恼除，我們可以采用“在聚合根中臨時保存領域事件”的方式予以改進：
public class Order {
private List<Event> events;
public Order() {
//create order
//...
events.add(new OrderPlacedEvent());
}
public List<Event> getEvents() {
return events;
}
public void clearEvents() {
events.clear();
}
}
在測試Order對象時，我們便你可以通過驗證events集合保證Order對象在創(chuàng)建時的確發(fā)布了OrderPlacedEvent事件：
@Test
public void shouldPublishEventWhenCreateOrder() {
Order order = new Order();
List<Event> events = order.getEvents();
assertEquals(1, events.size());
Event event = events.get(0);
assertTrue(event instanceof OrderPlacedEvent);
}
在這種方式中，聚合根對領域事件的保存只能是臨時的豁辉，在對該聚合根操作完成之后令野，我們應該將領域事件發(fā)布出去并及時清空events集合』占叮可以考慮在持久化聚合根時進行這樣的操作气破，在DDD中即為資源庫（Repository）：
public class OrderRepository {
private EventPublisher eventPublisher;
public void save(Order order) {
List<Event> events = order.getEvents();
events.forEach(event -> eventPublisher.publish(event));
order.clearEvents();
//save the order
//...
}
}
除此之外，還有一種與“臨時保存領域事件”相似的做法是“在聚合根方法中直接返回領域事件”餐抢，然后在Repository中進行發(fā)布现使。這種方式依然有很好的可測性，并且開發(fā)人員不用手動清空先前的事件集合旷痕，不過還是得記住在Repository中將事件發(fā)布出去碳锈。另外，這種方式不適合創(chuàng)建聚合根的場景欺抗，因為此時的創(chuàng)建過程既要返回聚合根本身售碳，又要返回領域事件。
這種方式也有不好的地方绞呈，比如它要求開發(fā)人員在每次更新聚合根時都必須記得清空events集合贸人，忘記這么做將為程序帶來嚴重的bug。不過雖然如此佃声，這依然是筆者比較推薦的方式灸姊。
業(yè)務操作和事件發(fā)布的原子性
雖然在不同聚合根之間我們采用了基于領域事件的最終一致性，但是在業(yè)務操作和事件發(fā)布之間我們依然需要采用強一致性秉溉，也即這兩者的發(fā)生應該是原子的力惯，要么全部成功，要么全部失敗召嘶，否則最終一致性根本無從談起父晶。以上文中“訂單積分”為例，如果客戶下單成功弄跌，但是事件發(fā)送失敗甲喝，下游的賬戶系統(tǒng)便拿不到事件，導致最終客戶的積分并不增加铛只。
要保證業(yè)務操作和事件發(fā)布之間的原子性埠胖，最直接的方法便是采用XA事務，比如Java中的JTA淳玩，這種方式由于其重量級并不被人們所看好直撤。但是，對于一些對性能要求不那么高的系統(tǒng)蜕着，這種方式未嘗不是一個選擇谋竖。一些開發(fā)框架已經(jīng)能夠支持獨立于應用服務器的XA事務管理器（如Atomikos和Bitronix）红柱，比如Spring Boot作為一個微服務框架便提供了對Atomikos和Bitronix的支持。
如果JTA不是你的選項蓖乘，那么可以考慮采用事件表的方式锤悄。這種方式首先將事件保存到聚合根所在的數(shù)據(jù)庫中，由于事件表和聚合根表同屬一個數(shù)據(jù)庫嘉抒，整個過程只需要一個本地事務就能完成零聚。然后，在一個單獨的后臺任務中讀取事件表中未發(fā)布的事件些侍，再將事件發(fā)布到消息中間件中隶症。
這種方式需要注意兩個問題，第一個是由于發(fā)布了事件之后需要將表中的事件標記成“已發(fā)布”狀態(tài)娩梨，即依然涉及到對數(shù)據(jù)庫的操作沿腰，因此發(fā)布事件和標記“已發(fā)布”之間需要原子性。當然狈定，此時依舊可以采用XA事務颂龙，但是這違背了采用事件表的初衷。一種解決方法是將事件的消費方創(chuàng)建成冪等的纽什，即消費方可以多次消費同一個事件而不污染系統(tǒng)數(shù)據(jù)措嵌。這個過程大致為：整個過程中事件發(fā)送和數(shù)據(jù)庫更新采用各自的事務管理，此時有可能發(fā)生的情況是事件發(fā)送成功而數(shù)據(jù)庫更新失敗芦缰，這樣在下一次事件發(fā)布操作中企巢，由于先前發(fā)布過的事件在數(shù)據(jù)庫中依然是“未發(fā)布”狀態(tài)，該事件將被重新發(fā)布到消息系統(tǒng)中让蕾，導致事件重復浪规，但由于事件的消費方是冪等的，因此事件重復不會存在問題探孝。
另外一個需要注意的問題是持久化機制的選擇笋婿。其實對于DDD中的聚合根來說，NoSQL是相比于關系型數(shù)據(jù)庫更合適的選擇顿颅，比如用MongoDB的Document保存聚合根便是種很自然的方式缸濒。但是多數(shù)NoSQL是不支持ACID的，也就是說不能保證聚合更新和事件發(fā)布之間的原子性粱腻。還好庇配，關系型數(shù)據(jù)庫也在向NoSQL方向發(fā)展，比如新版本的PostgreSQL(版本9.4)和MySQL（版本5.7）已經(jīng)能夠提供具備NoSQL特征的JSON存儲和基于JSON的查詢绍些。此時捞慌，我們可以考慮將聚合根序列化成JSON格式的數(shù)據(jù)進行保存，從而避免了使用重量級的ORM工具遇革，又可以在多個數(shù)據(jù)之間保證ACID卿闹，何樂而不為揭糕？
總結
領域事件主要用于解耦微服務萝快，此時各個微服務之間將形成最終一致性锻霎。事件風暴活動有助于我們對微服務進行拆分，并且有助于我們深入了解某個領域揪漩。領域事件作為已經(jīng)發(fā)生過的歷史數(shù)據(jù)旋恼，在建模時應該將其創(chuàng)建為不可變的特殊值對象。存在多種方式用于發(fā)布領域事件糙俗，其中“在聚合中臨時保存領域事件”的方式是值得推崇的壮韭。另外北滥，我們需要考慮到聚合更新和事件發(fā)布之間的原子性，可以考慮使用XA事務或者采用單獨的事件表蜀细。為了避免事件重復帶來的問題，最好的方式是將事件的消費方創(chuàng)建為冪等的戈盈。
更多精彩洞見奠衔，請關注微信公眾號：思特沃克
