Conditions in Event Storming

user_12765965 0
Viewed 246

I will explain this as an Album application problem.

I want to create a new Album but the Artist of that Album is not created yet.

There are 2 solutions to solve this problem:

  1. Create the Artist first, then create the Album
  2. When creating the Album, check if the Artist is created. If the Artist is not created, then create a new Artist and save that information to the Album.

I chose solution 2 and I want to present this using Event Storming.

I don't know how to present the solution correctly in timeline order.

So I have come to this.

My Event Storming Board

I don't know if my solution is correct or not :(

And if it isn't, how to correctly present this?

domain-driven-design
2 Answers

I would try to make each step explicit so that you also can easily spot what transactions happen to what aggregate. So I assume you see artist and album as separate aggregates (not relevant for now if they live in the same bounded context or not). I would approach it in an event storming session somewhat like this:

  • --> Create Album (Command)
  • --> Album Created (Event)
  • --> Check Artist of Created Album (Policy)
  • --> Create Artist (Command)
  • --> Artist Created (Event)
  • --> Check for Existing Albums of New Artist (Policy)
  • --> Link Artist to Album (Command)
  • --> Artist of Album Updated (Event)

For me the policies usually mean: when policy X applies then perform command Y.

With that flow you would also guarantee that only one aggregate is created/modified at a time. Your current approach binds the simple creation of a new album to lots of other responsibilities in one go (e.g. checking if the artist already exists, if yes, creating the artist and afterwards creating the album). I like to get the most essential stuff done as quickly and simple as possible and separate subsequent steps. So here I would consider the creation of the album the highest goal of the user of the application. Because if they haven't created the artist first they obviously like to focus on album creation now more. If the artist entity is created in a second step should then be not of so much concern for the user.

user_77305540

It really depends why your business needs to know that an album has an artist.

On the face of it, I would say that both album and artist, if they are separate aggregates, should be created independently and exist regardless of there being a link between the two. You do not want to implement referential integrity between aggregates, it is eventual consistency. All should be able to exist without the other, it is just in a state of not having all information.

If you actually want to prevent the album from being created without there being an artist, then there should be a policy in which you will decide to create an album, but this will result in a create artist command, as the album needs an artist first.

If an artist already exists it is as simple as:

Create Album Policy -> Create Album -> Album -> Album Created

When an artist does not exist I would do something like this:

Create Album Policy -> Create Artist Command -> Artist -> Artist Created Event -> Create Album For New Artist Policy -> Create Album -> Album -> Album Created

These make sense when you have manual policies with a user, however if it is entirely automated then you might actually be talking about a single command and you might need to reconsider your aggregates, or at least your aggregate root.

user_10772140
Related