How about integration events ?

[NicolasReyDotNet]

Hi @alexeyzimarev ,

first let met say that, it's the first time a buy a dev book and I'm not disappointed about it. I did learn so much with your approach, it's clear, well explained, the examples are great and the code is not overkilling me.

I have a point : I need to exchange some event (integration event if I'm right) between bounded contexts, and thus between Microservices, using a message broker.

1) But where the publish of this event is supposed to be played ? If we take the ClassifiedAds aggregate as example, where the publish of the event is supposed to be placed in your point of view ? At the end of the Apply method of aggregate roots ? (you briefly talk about it in Chapter 5 p141 but it was before you build your entire class logic)

2) When we construct back our aggregate from the event store (in case of event sourcing), we replay all the events, but how avoiding sending some integration event that may lead to confusion : example an event that trigger an email sending to a customer on an order shipped, we don't want to send an email each time we construct our aggregate back from scratch. What are the best practices ?

Many thanks

[alexeyzimarev]

Integration has indeed not been properly covered in the book just because it's a big topic on its own.

To properly integrate different contexts you need to ensure you establish a communication language, which isn't necessarily the same language as the one used inside the context.

Consider creating a set of message contracts for integration purposes only. Events might just be the same as domain events at the start but you don't want to find yourself bound to external dependencies when you need to change your domain logic (it will happen).

Establish a reliable event publishing flow, detached from the persistence flow. Remember, don't mix persistence with anything else as it is transactional. Therefore, create a simple subscriber to an Event Store stream that will get domain events, convert them to integration events and publish to the broker. It will be asynchronous and won't interfere with the persistence.

[NicolasReyDotNet]

@alexeyzimarev Thank you for the advices, the idea of subscribing to the EventStore in case of Event sourcing is brilliant! I think I understand what you mean about extending the event from the context : a subscriber may needs more that one event "context information" so we may enrich the integration event before publishing it.

[alexeyzimarev]

It is quite common to expand events in order to fulfil the needs of downstream system needs. Mathias Verraes formulated it nicely in the Fat Events article. It is, albeit, a bit different from the integration vs domain events separation. My heuristic there is to establish what Eric Evans calls Interchange Language and keep your domain events isolated from it. To start with, think about keeping your domain model, represented by domain events, free from external concerns. Make sure that you're free to evolve your domain model according to the needs of the domain itself, keeping external contracts stable at the same time.

[paulvanbladel]

hi @alexeyzimarev . Any news related to the last chapter of the book? cheers paul

[alexeyzimarev]

@paulvanbladel what do you mean? it is published online since summer last year.

[paulvanbladel]

online the last chapter is chapter 12 (bounded context). You mean with online: https://subscription.packtpub.com/book/application_development/.... The repo has a chapter 13, no?

[alexeyzimarev]

No, the link to Chapter 13 is in the book Preface.

[paulvanbladel]

@alexeyzimarev ok, that's great info. Can't wait reading it Alex. Your book is really very very good.

[alexeyzimarev]

Thank you, Paul, I appreciate your feedback 👍