0

I have a discussion with a colleague regarding how to model a command that immediately gets an answer to it's HTTP POST request back. In this specific case we do an API call to a 3rd party IDP API that we don't control, we'll do a HTTP post and get a response.

There are two statements from him regarding this:

  1. Event Storming is NOT about implementation.
  2. We want to do EDA, therefore we MUST use events everywhere.

The first one MIGHT be true, but the implementation then has to follow the process somehow and therefore I think they are equal.

The diagram (2) below is wrong in my opinion because the HTTP response is not an event and the follow-up action is NOT triggered by an event but the outcome of the HTTP call, which is, by its nature async, but from the perspective of the system it is still a process that requires a specific execution order and relies on the immediate outcome of the request.

However, I'm not happy with (1) in the diagram either. So how do you express that the immediate result of a command is the condition to proceed with the process and not an event? Is that at all correct?

enter image description here

Proposed by Thomas in the comments: enter image description here

floriank
  • 493

2 Answers2

0

in my opinion because the HTTP response is not an event

It might be useful to revise that opinion (see: Fuzzy Definitions).

What I would expect to see:

  • The 3rd party API represented as an external system (large pink sticky)
  • The HTTP request represented as a command sent to that external system
  • The HTTP response represented as an event triggered by that external system

For example:

Blue: VerifyIdentity -> Pink: IDP API -> Yellow: IdentityVerified

External systems triggering events is one of the primary cases called out in Chapter 14.

The HTTP response triggers a state change (we transition from "we don't know who this is" to "the IDP has told us who this is").

It might help to think about the alternative: what would you show if you were trying to model how the system behaves when the network is unreliable?

Blue: VerifyIdentity -> Pink: IDP API -> ??????: IdentityVerificationTimedOut

That certainly sounds to me like an "event" (although you might quibble about whether the event is triggered by the IDP API or some clock somewhere).

VoiceOfUnreason
  • 34,589
  • 2
  • 44
  • 83
0

We want to do EDA, therefore we MUST use events everywhere

The thing is, usually you don't want to do EDA, but you have to, because you anticipate (or already have) scaling issues, and the traditional request/response approach is not enough. Request/response approach is simpler and imposes less overhead, so totally go for it if you can afford it performance-wise. EDA is not a holy grail, it's a tool for solving a specific set of problems, and it comes with a cost. You don't have to shoehorn your whole system for the sake of it.

Yes, you can do some mental gymnastics and and claim that HTTP response is an event. It's not exactly wrong, given the broad definition of "event". The question is, what problem EDA solves in this particular case? "We want to do EDA, therefore we MUST use events everywhere" is a weak justification

Anton Pastukhov
  • 383