How to model integration based on events compared to commands?

[cremich]

Hey ddd-crew,

in preparation of a workshop, I did a modeling test run. During this test a question came to my mind.

How do you model an event-based integration between two bounded contexts (BC A and BC B) with a domain message flow diagram? The command-based integration is easy. BC A sends a message to BC B.

But what if we aim for an approach based on an event-based integration. In this case BC A emits an event that BC B is subsribed to?

Lets make it a bit more explicit based on the example in this repo:

• The sales BC is subscribed to "Payment collected" events
• The billing BC emits the event "Payment collected"

Looking into the language in the example, step 5 gives me the hint that we are integrating based on events (Payment collected). But the arrow-direction from the billing BC to the sales BC confuses me a bit. This would suggest command-based integration rather than event-based integration. I would not expect a direct connection from the billing BC to the sales BC when using events.

What do you think? How do you visualize event based integrations?

Best,
Christian

[NTCoding]

Hi @cremich.

The current notation is designed to show that a message is produced by the context at the start of an arrow and is received by the context at the end of the arrow. Basically "a message starts here (at the start of the line) and ends up here (at the end of the line)".

You're right that for events it's a logical pull rather than a push (commands). My assumption is that I can work out push/pull by looking at the message type. But it's good to get your alternative perspective because other people are probably feeling the same confusion as well.

Do you have any suggestions about a notation that would make it clearer for you?

[cremich]

I like the visualization, you and Scott have chosen in your book "Patterns, Principles, and Practices of Domain-Driven-Design". Commands and Events are represented by two different types of arrows. The solid one for commands, the dashed one for events. (See Figure 12.3 on page 188 for example)

One idea that came to my mind, if this could also help in a domain-message-flow diagram.

[NTCoding]

@cremich the significance of events vs commands does justify giving each a unique notation. On the other hand, the reason I recommend starting with these simple diagrams is that sometimes commands vs events can be a slight hurdle for newcomers.

I'd like to get a range of diverse opinions like yours and discuss as a group. So I think this would be a good topic for a virtual DDD. Would you be interesting in co-designing and co-facilitating a session together, maybe sometime in mid June?

[AlexZeitler]

The solid one for commands, the dashed one for events.

We’re using this notation in PlantUML sequence diagrams when modeling such scenarios.

[MerrionComputing]

You could use an intermediary icon to represent the message broker?
(Although the arrows end up going the same way)

[cremich]

@cremich the significance of events vs commands does justify giving each a unique notation. On the other hand, the reason I recommend starting with these simple diagrams is that sometimes commands vs events can be a slight hurdle for newcomers.

I'd like to get a range of diverse opinions like yours and discuss as a group. So I think this would be a good topic for a virtual DDD. Would you be interesting in co-designing and co-facilitating a session together, maybe sometime in mid June?

Oh cool. Sounds good. I am in :)

Keeping the diagram type simple is definitely valuable. And therefore adding new asset should be be carefully considered.
Maybe it is worth seeing it from a different perspective. If I have two independent contexts, how are events distributed in my system? Is there something like a eventbus in between? If yes, a explicit presentation could be:

BC A emits an event on the event bus (or whatever system is responsible for publishing events in the system). And this components sends the event to BC B visualized by sending a "message" in our domain-flow.

[baruica]

I feel the same as @cremich, I don't like that events and commands are both associated with the same kind of arrow.
What about
agg/BC ---> event ---> other BC
to emphasize that the event is broadcasted and maybe listened to once "in the air" ?

[NTCoding]

Some great ideas in here. We're working on setting up a meetup where we can do this as a group activity. I'll let you know when it's confirmed. Currently some of the team are taking a break after the conference last week but I think next week we should have something to put in the calendar.

[NTCoding]

I'm looking to organise a meetup for this late July or early August. Anyone who is interested, please share any dates that do or don't work for you. Thanks

[asidhu11702]

Hi there how can I use this diagram? Is it on miro board or lucid chart. I really want to use this but dont know how to use it. please help

[NTCoding]

Hello @asidhu11702. Apologies for the delay I've been on vacation for a couple of weeks.

For the virtual templates, check out this repo: https://github.com/ddd-crew/virtual-modelling-templates.

Have fun and please let me know if you need anything else.

[NTCoding]

The meetup has now been organised. Anybody in this thread who wants to attend but could not get a place, please let me know.

https://www.meetup.com/Virtual-Domain-Driven-Design-meetup/events/271938901/