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
  • 471
  • 2
  • 16
  • 1
    I'm having trouble understanding your diagrams. I would expect that "Our Service" receives a command from another service or broker and executes it. "Handling", in this case, would be creating the HTTP POST request to the External Service, reading the response code, publishing the relevant event(s) back to the broker or subscribers, and then continuing with the next command. I don't see this in either diagram. – Thomas Owens Aug 21 '23 at 11:48
  • I put the command in our service because this is the origin of the command. The external service is the receiver or processor. Is there actually any written documentation and formalization regarding how to draw this? – floriank Aug 21 '23 at 13:59
  • I would recommend looking at the [C4 modeling language](https://c4model.com/) for structural diagrams. For a question like this, the Container diagram level would be the most interesting, showing elements like your various services, message queues and brokers, databases, and external services and the types of connections between them. You may need to drop into flowcharts or even UML Sequence, Communication, or Activity diagrams for showing how data and messages flow through the system. It gets confusing when structural and behavioral elements are mixed onto a single diagram. – Thomas Owens Aug 21 '23 at 14:03
  • "It gets confusing when structural and behavioral elements are mixed onto a single diagram" - I totally agree. The diagram type in question is about behavior, it's an event-storming diagram. – floriank Aug 21 '23 at 14:06
  • I have updated the question with a 3rd diagram based on what you wrote before. – floriank Aug 21 '23 at 14:07
  • The third diagram is not what I describe at all. Does this system exist at this point? Or are you doing speculative design? – Thomas Owens Aug 21 '23 at 14:09
  • It exists. It can be any Oauth2 provider and we don't control them. – floriank Aug 21 '23 at 15:09
  • I don't mean the external identity provider. I mean these events. If you're trying to describe an as-built system, you'll need more information. Where are your events stored - what kind of queue or broker system do you use? How do your services communicate with that storage system, minimally considering push vs pull or protocols? – Thomas Owens Aug 21 '23 at 15:16

1 Answers1

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
  • 32,131
  • 2
  • 42
  • 79
  • Thank you! But why is the response considered to be an event? This is what I personally struggle to comprehend. The external systems call fails and returns that or it is successful and returns that. The state change happens only when the call is successful. And if its successful or not is up to the interpretation of the caller. – floriank Aug 21 '23 at 13:57
  • "why is the response considered to be an event?" The response is a message with information from an authoritative source. – VoiceOfUnreason Aug 21 '23 at 14:09
  • @floriank: You're getting lost in the details here (which matches what your coworker also remarked). Just because a happy path HTTP response can be put on the diagram as an event does not automatically mean that your implementation must always generate an event no matter what kind of response you get from the HTTP request. Those are two very different things and I think you're struggling to separate the high level design from the low level implementation. – Flater Aug 22 '23 at 03:31