'Event Storming : Domain Event "Add to Cart Requested" is Good or Bad practice?
I have a question about "Domain Events"(orange post-it) in Event Storming
When I look some examples of Event Storming, I sometimes see Domain Events that look like this:
- "Order cancellation Requested"
- "Add to Cart Requested"
- "Ticket Requested"
- "Create Account Requested"
- ...
However I'm wondering if it's a good practice to create orange post-it like this, because it creates a kind of repetition. For example :
If i add this post-it :"Create Account Requested", I should also have "Account Created" post-it.
If i add this post-it :"Add to Cart Requested", I should also have "Added to Cart" post-it.
If i add this post-it : "Order cancellation Requested", I should also have "Order Canceled" post-it.
...
And I feel like it's a bad practice because that multiplies the number of post-it by 2 in my opinion.
If you think it's interesting to have orange post-its like this, can you explain why? If you think it is not,can you explain too ?
Thank you for your future anwsers.
Solution 1:[1]
As with everything in domain driven design, it depends on the domain.
As a general rule, domain events are those which change the state of the system in some way, which generally means that there needs to be at least one command or query somewhere in the system which has a different result/effect in the universe where that event is recorded (i.e. stored, broadcast, whatever) from in the universe where that event is forgotten/ignored. If there's no command or query that's affected by this event, it's almost certainly not a domain event.
So for AddToCartRequested, if nothing changes unless and until there's an AddedToCart event, then AddToCartRequested isn't a domain event. But if there's a process with its own state for adding an item to the cart (e.g. it's a saga), then the AddToCartRequested event changes some state (it might for instance reserve inventory of the item if the business is willing to lose a sale in order to avoid having to perform a compensatory transaction) and is a bona fide domain event (it's probably a good idea to also have an AddToCartRejected domain event which returns things to the approximate status quo).
Note that there's an interesting question about whether observability (e.g. grafana or whatever) constitutes a read model for your domain: from this perspective, having a graph of attempts to add items to carts would be a query which is affected by the presence or absence of the event. (This perspective leads to an argument that nearly all logging and/or application-level metrics are just really crude domain events...).
Solution 2:[2]
Explicitly modelling some action is a good thing. Because this way it becomes obvious, that there is an actor involved. Hence, there should be some interface in the implemented system.
These are definitely events, because we think of them as of something that has taken place. But they are very different from events in a sense of, e.g. Event Sourcing (not Storming). They are ephemeral and lead to other events, which we used to call domain events. That kind of events that reflect a change of the state of the domain.
To me an event from the first group is more like a stepping stone from events-outcomes to the intents that trigger the interaction.
It is very logical and useful for unwinding the flow.
Changed state: added to cart. What leads to it? Add to cart requested. What has triggered it? Customer added an item to cart.
Would I spend a card on such ephemeral "events"? If it brings additional clarity - then definitely yes. Because it helps experts-to-developers communication. If it is obvious to the storming parties, especially developers, - then probably no... Because it adds noise without adding value.
Solution 3:[3]
All these events strike me as typical steps in a UI. These seem to be notifications, not domain events and I would squash them into a single policy and command that tries to accomplish the final command which results in the domain actually doing something.
However the use of "Requested" could be valid if the notion of something being requested was important to the domain, such as Order Cancelation Requested leading to the domain approving the cancellation and Order Cancellation Request Approved triggering the order to actually be cancelled and finally Order Cancelled event
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Levi Ramsey |
| Solution 2 | |
| Solution 3 | Kieran |