LLMs are pretty good at EventStorming

Stephan Eggermont

— 2 min read
What is EventStorming?
EventStorming is a collaborative design practice invented by Alberto Brandolini. It is a group brainstorming process using paper, post-its and pens, to collaboratively build a shared model of a domain.

I am pleasantly surprised by the technical results of applying an LLM to do EventStorming. Recently, my friends at QWAN made available their DDD EventStorming workshop case. It is a text about an internal training courses system

We want to grow a culture of learning and growth and support our employees in their personal development. Specifically, we want to look at how we can facilitate internal training courses designed and delivered by our own people.

I gave ChatGPT the following prompt: I need you to get me the events in terms of an event storming workshop for the following case. Be detailed, and put them in the right workflow order: and then added the full text from the case. It consists of a page and a half describing domain concepts and their relationships and attributes:

...We have employees that can create and deliver courses - ‘teachers’ - and every employee can attend courses, as a ‘student’. All our employees are known within our IAM system (Identity and Access Management). Teachers can define new courses, update their courses, or retire them. A course has a name, code, description, duration, student preparation, points, and optional links to other courses, e.g. prerequisite courses...

The results were really usable, 11 domains with in total 57 events found:

1. Course Lifecycle Management
Domain Actors: Teacher, System
Key Aggregates: Course
TeacherDefinedCourse
CourseDetailsUpdated
CourseRetired
Data Model Note: Course has name, code, description, duration, student preparation, points, prerequisites.

Asking What attributes need to be stored by each of these events. Be detailed then resulted in a detailed list for all of them

1. Course Lifecycle Management

TeacherDefinedCourse

  • courseId
  • teacherId
  • courseName
  • courseCode
  • description
  • duration
  • studentPreparation (e.g., materials or tasks)
  • points
  • prerequisiteCourseIds (optional)
  • linkedCourseIds (optional)
  • createdAt

CourseDetailsUpdated

  • courseId
  • updatedFields (partial object showing only changed fields)
  • updatedBy (teacherId)
  • updatedAt

CourseRetired

  • courseId
  • retiredBy (teacherId)
  • retiredAt

This looks really good, and was a lot faster than I can identify them myself. The coverage and completeness is good, and it turns out to be a pretty good artefact to help building a system. But don't forget what Alberto Brandolini has to say about the outcome:

It’s easy to mistake the artefact for the actual workshop outcome. It’s big and colourful and provides a reference shape for your business.

This is great, but the conversations needed to build the shared model are usually the most valuable outcome of the workshop. They dig into years and misunderstandings and across silo boundaries to provide clarity and confidence to key people in your organisation.

When you can finally observe your system as a cohesive whole, you enable change. People are afraid of breaking invisible things, and our relentless effort to make everything visible turns even the most intricate businesses into systems that can be improved.

This is of course something that I have not achieved with this approach

This post is using material covered under https://creativecommons.org/licenses/by-sa/4.0/deed.en and therefore also covered by it.

Read more