张逸说

我在GitChat发布的《领域驱动战略设计》课程于2018年10月结束，原计划是在2018年底或2019年初再发布《领域驱动战术设计》课程，没想到一拖再拖，而我自己也终于体会到起点作者的那种催更压力。我本想揣着鸵鸟的心态躲在后面默默地写、慢慢地写，不给自己设定最终期限，没想到读者群里的众多读者已经开始发出了自己的呼声：

我想，我没法再藏起来假装自己不知道，只得站出来给大家汇报。

我在Martin Fowler网站上读到一篇名为How to break a Monolith into Microservices的微服务文章，作者为ThoughtWorks的咨询师Zhamak Dehghani，介绍了如何从单体架构演进到微服务架构。

本文内容来自我的知识星球「逸派胡言」对群友提出的有关领域驱动设计基本概念的回答。

我们开发的一个基于大数据平台的数据仓库，选择了Flink作为数据处理的底层框架。我们主要看重于它在流处理的低延迟性，消息传递保证的extractly once特性；它为流处理和批处理提供了相对统一的API，支持Java、Scala和Python等主流开发语言，同时还较好地支持了SQL。Flink搭建了非常棒的基础设施，例如它可以和ZooKeeper、YARN集成起来，保证处理功能的高可用性与水平扩展的集群能力，同时还提供了相对开放的扩展能力，使得我们可以较容易地在已有功能基础之上实现定制开发。

个人认为，相比较传统领域分析方法，事件风暴的革命意义在于它建立了以“领域事件”为核心的建模思路，这相当于改变了我们观察业务领域的世界观。当我们在理解业务需求时，我们看到的常常是功能、流程，并通过从需求描述中梳理领域概念，进而借助这些概念去识别那些参与到业务场景中互为协作的领域对象，这往往让我们忽略了一个在任何领域中都必须存在的概念，即“事件”。这些事件是每次用户操作、业务活动留下来的不可磨灭的足迹，它牵涉到状态的迁移，业务事实的发生，忠实地记录了每次执行命令后可能产生的结果。倘若这些事件还直接影响到该领域的运营和管理时，则可以将它们认为是“关键事件”。

正如Martin Fowler对领域事件的定义：“重要的事件肯定会在系统其它地方引起反应，因此理解为什么会有这些反应同样也很重要。”在识别和理解事件时，正是要从这样的因果关系着手，考虑为什么要产生这一事件，以及为什么要响应这一事件，进而思考如何响应这个事件，驱动着设计者的“心流”不断思考下去，就像搅动了一场激荡湍急的风暴一般。我想着或许是Alberto Brandolini将其命名为事件风暴的缘由吧。