領域驅動設計（domain-driven design，DDD）通常在微服務領域用于查找邊界（限界上下文）。同樣來自DDD的聚合（aggregate）對于定義持久化和一致性的范圍來講也是很重要的。 但是，并不是領域驅動設計中的所有內容都適合微服務，Lutz Huehnken在柏林舉辦的microxchg 2018的演講中討論了如何使用DDD、事件風暴（Event Storming）和基于Akka的Lagom框架來構建反應式系統，在這個過程中模型與實現會按照1-1的方式進行映射。

在DDD中，傳統上會關注系統的靜態結構，當我們與領域專家交流的時候會聆聽他們的名詞。Huehnken是一位獨立咨詢顧問，對他來講關注靜態屬性通常會導致糟糕的邊界。因此，他主張我們應該關注動態性和事件。在設計的初期階段，至關重要的并不是事物，而是所發生的事情。

事件風暴

事件風暴主要是來自DDD社區的一個工作坊，用于快速探索復雜的業務領域。在這個過程中，會使用一面大墻作為建模面，并使用貼紙來代表模型。我們將業務人員和開發人員聚集起來，并采用事件的方式查找領域中所發生的事情。當找到事件時，會嘗試沿著一個時間線對它們進行排序。隨后，我們會添加觸發每個事件的命令。Huehnken在這里沒有基于實體看上去的從屬關系創建聚合，而是希望能夠根據命令流和事件而生成聚合。這會給聚合帶來不同的視角，它會對命令和事件一起進行邏輯分組，他相信這種方式能夠為我們帶來更好的邊界劃分，并且有助于將聚合分割到不同的服務中。

在Huehnken的經驗中，事件風暴是一個強大的工具，在一些較大規模的場景中更是如此，但是它可以用于不同的級別。他發現我們還可以將其用到一個更加技術化的級別，用于建模服務和聚合。這種方式的一個巨大優勢就是能夠將模型和實現匹配起來，這在DDD中是非常重要的。

反應式系統

反應式系統指的是構建具備即時響應性、彈性、適應性以及消息驅動特征的系統。實現這些特征的方式是異步消息。對于Huehnken來說，微服務的關鍵點在于隔離、快速反應并且能夠在部署新版本服務時不影響系統的其他組成部分，所以對他來說，這兩個概念非常具有互補性，我們需要反應式的微服務。

實現反應式系統的教科書式技術是Actor，但是Huehnken認為這種模型并不像他想象中的那樣被廣泛采用，他相信造成這一點的原因在于從單體模型進行轉移所需的思想方式轉變。在單體模型中，我們可以訪問任何的內容，甚至可以跨越已存的邏輯邊界。在真正的分布式系統中，會具有網絡邊界，我們無法以整體的方式訪問系統。涉及到多個聚合的業務進程可能會需要像sagas這樣的模式。現在，我們還要告別全局狀態，在分布式系統中，每個服務是本地化的，已經過去的事情要通過事件來表示。

Huehnken認為我們已經有了一個非常有趣的采用Actor的實現技術。現在有多個可用的框架，包括Erlang和Akka。Lagom是一個更新、更具傾向性的微服務框架，它基于Akka、CQRS和事件溯源（event sourcing）。因為思維方式的挑戰，人們在構建復雜異步解耦的系統時還較為困難，但是如果我們想要將建模技術和實現技術結合起來，這將是一個非常好的機會。

在DDD中，非常重要的一點在于代碼要表述模型的概念。Huehnken認為我們在這一點上已經迷失并且在偏離方向。我們已經開發了實現技術，并且又獨立開發了新的建模技術，現在我們必須將它們結合起來，這樣來自模型的理念能夠直接反射到代碼中，這樣的話，會在構建分布式系統方面取得真正的突破。

會議演講的視頻進行了錄制，其中有一部分已經發布，更多的視頻稍后會發布。

相關文章：

• Actor-ES框架：Ray

• Actor-ES框架：Ray--事件（Event）編寫說明

• Ray框架Q&A

• Actor-ES框架：Ray-Handler之CoreHandler編寫

• Actor-ES框架：Ray-Handler之ToReadHandler編寫
  

原文地址:http://www.infoq.com/cn/news/2018/04/reactive-actors-eventstorming

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的使用DDD、事件风暴和Actor来设计反应式系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。