事件风暴教程

EventStorming是一种基于研讨会的方法，可以快速找出软件程序领域中正在发生的事情。与其他方法相比，它非常轻巧，不需要计算机的特别支持。在宽阔的墙上的粘便笺表示。业务流程被“冲出”为一系列领域事件，这些事件被表示为橙色便签（维基百科定义）我与EventStorming的第一次

这两种建模方式都是围绕事件展开，但是有区别，事件风暴将会比普通的事件建模在思考层次上更高级，这需要从思维机制讨论：大脑是一个处理信息的机器，它学习速度很快，可以立即处理数据负载。那么，知识是如何构建的？在何处存储？人的记忆可以分为两类：语义记忆和情景记忆。 情

我们总结了“协作建模”（以下简称“ CoMo”）背后的想法和概念。在“敏捷”和“领域驱动”之后，我们将“ CoMo”视为商业软件开发的下一个重大步骤。 什么是协作建模？几年前，我们的三个同事被要求更换客户的

全面的业务流程管理（BPM）依赖于最简单的技术之一：业务流程映射。业务流程映射是流程性能改进和技术创新计划中必不可少的技术。使用BPMN流程图不仅是方框和箭头，还揭示了工作完成方式和方式的“魔力”和智慧。可悲的是，太多的专业人员给过程映射带来了麻烦。这里有10个技巧，可确保流程映射可

将大型复杂系统模块化为更小和更易于管理的部分是一种最佳实践，这不仅是为了降低每个部分的认知负担，而且还可以降低团队的独立性和运营弹性。棘手的一点是如何划定边界，使整个系统稳定而可持续。带有边界的上下文是领域驱动设计的一种方法，业务领域的语言用作指导，还有另一种方法是从业务模型定义的功

两个概念之间的耦合与某些属性有关。不论哪个属性更改都会影响一起更改的内容。我们的有界上下文边界划分是一种押注，押注那些会一起改变的事情。

EventStorming是超越孤岛边界进行协作的最明智的方法。EventStorming的力量来自于一个多元的，多学科的人群，他们在一起拥有很多智慧和知识。虽然最初是为研讨会设计的，以模拟领域驱动的设计集合，但现在它的应用范围更广。从获得整个领域的全局问题空间到深入了解整个软件交付流程并制

DDD不是聚合、事件溯源、CQRS、事件风暴等。这些都是工具。它们已被证明在DDD项目中非常有用。但是我们必须小心，不要将演奏乐器与音乐艺术混淆。对我而言，这是DDD的关键是：与大型系统的复杂性作斗争时，项目团队如何获取领域知识，他们如何构建、开发和普及应用概念模型，以及随着时间的推

领域事件(Domain Events)与事件溯源(EventSourcing)有什么共同点？名称中都有“事件”一词。但是除此之外，在项目，会议或培训中与架构师和开发人员交谈时，我经常听到领域事件与事件源配合得很好，并且事件源是领域事件的理想来源。在此博客文章中，我想概述为什么我个人不同意这种

事件建模的创始人Alberto Brandolini说：数据是在有界上下文之间流动的，而行为是特定于某个有界上下文方式的。如果围绕数据划分微服务边界将导致分布式耦合。这不是我最喜欢的方式。（banq注：按动词如行为或事件寻找上下文之间边界，以此划分微服务边界，不是根据对象的数据属性，一个对象

语言是思考的操作系统。与没有语言相比，有语言可以思考更多，不是所有语言都是平等的，而书面语言则可以考虑更多。表达思想（特别是语言）的系统的一个关键特性是，通过将我们的短暂思想编码为可以观察和推理的其他事物，它们使思想变得具有反思性和递归性。他们使得思考我们的想法成为可能。语言

应用程序开发中最困难的部分是如何确定客户的实际需求。一种方式是开发团队可以精心设计软件需求，直至细节；还有一种观点：认为解决需求问题的最佳方法是完全放弃需求，而选择快速的软件原型。加利福尼亚州针对政府的立法数据中心的IT经理说：“不再有书面要求。” “相反，我们与客户组成一个小组，找

消息传递模式的严重错误，导致巨大的耦合和极端的意外复杂性：少而巨大的事件多个服务都可以发布相同的事件每个服务都会改变事件的一部分并重新发布众说纷纭：最后一个在基于文档的消息传递中很常见，可以了！实际上，根据问题空

事件建模对信息系统而言比对敏捷性所希望的更为真实。 以我的经验，“敏捷”意味着没有雇用足够的人员，而没有进行充分的测试，完善的用户界面或编写文档，产品会失败。也许它应该意味着其他事情，但这是我的经验。 在