Event Storming for peer-to-peer payments
As we saw in the Event Storming section, in an Event Storming session it's important to have a variety of representations from different departments in order to have meaningful discussions. In this case, let's suppose we have business analysts, chief architects, site reliability engineers, and UX designers. This is what our wall may look like after our brainstorming session:
Figure 2.6 – Event Storming for peer-to-peer payment
As you can see from the preceding diagram, even in this simplified example we begin to develop a clear picture of the people involved in this use case and the external systems.
We can see that two systems are identified, Identity Management (IDM) for dealing with customer profiles and Backend for dealing with balances and transactions.
In terms of command and domain events, this is something you may want to reiterate in order to understand whether more interactions are needed...
