From domain story to event storm
In the last couple of posts, we looked at domain storytelling and EventStorming. There’s a lot to like in either workshop format, but it’s not very efficient to do them both. What if we could get the benefits from both without having to organize two workshops?
Let’s look at the artifacts that the two workshops produce, and the elements these contain:
| Domain story | Event storm |
|---|---|
| Actor | User |
| Activity | Command, Event, Policy |
| Work object | Aggregate, Read model |
| Computer system | External system, Aggregate, Policy, Read model |
There is some correspondence between the objects in a domain story and an event storm. It’s not exactly 1:1, but you can see that with some cleverness we could map from domain story elements to event storm elements. The mapping does involve some subtleties, however.
For instance, not every work object will be its own aggregate. Some work objects may be entities inside another aggregate. Some may map to a read model instead.
Similarly, a computer system could map to an external system, or it could be the system under consideration itself. In the latter case, we’d break it up into aggregates, policies, and read models.
Given these caveats, it looks like we can have the best of both worlds: use domain storytelling for requirements elicitation and then convert domain stories to event storms. The latter exercise is actually doing high-level design.