As a fan of CQRS for many years, I really enjoy your videos. Small feedback, it might be useful to include more examples on ths slides that relate to what you're talking about. E.g. for the "Business concepts that are stable" maybe an example that is and isn't a business concept for others that may be unfamiliar would help. Cheers.
I feel that passing domain-specific events outside of the domain boundary will lead to a higher level of coupling, making it harder to change the source domain. I've always found it best to firmly separate my architectural boundaries, even if (especially if) "it will be fine right now". Thanks for the video.
I agree, generally. It's a safer bet. I have found that solid well understood domain events to almost never change in any breaking way. But if you're understanding isn't solid, then yes it will likely change.
I've been really impressed by how intentionally and precisely you treat concepts in your videos, Derek. Thank you for making these available! Would you consider making something like a "beginner to pro" playlist at some point? I'd love to point more people to your videos but there are so many (and many of them require some level of background in the subject) that it's hard to know where to start. ... Or maybe this is a problem that your upcoming course will solve? 😉 Also, I'd love to hear a review from you of the content in Juval Lowy's book "Righting Software" (part 1 - the part that deals with system design and volatility-based decomposition). I have been recommending that book to our senior team members and it provides some very interesting looks at these nuances of where and when coupling is safe, and why.
You're not the first person to mention that having a playlist or more natural transition from one concept to the other would be helpful. That is the intent of the course that I'm working on. Appreciate the comment! Also, I've not read the book but will check it out. Thanks for the suggestion!
I'm late to the discussion, but I personally think that it's not about Domain or Integration Events, but about internal vs. external events. When it comes to bounded contexts, they usually all belong to the same domain. So all events that are implemented in this domain of bounded contexts are domain events. I don't like the term integration events, because in the end all kinds of events are eventually for the integration of loosely coupled building blocks. For me there are two kinds of events: Internal events, often in-memory and sychronously managed as you told in your video - like Application Events in the Spring framework. And there are external events that belong to the public API of the bounded context. They must conform to some kind of messaging and serialization framework and must be versioned. Technically they are implemented at different packages with different visibility, so it's quite clear they have to be strictly separated from the internal ones.
When it comes to integration events maybe for building projections for BFFs for example, if you’re shipping them over a message broker how do you do replays? Do you have to create tooling that would publish messages from various persistent streams (like in EventStore) to a certain pubsub subscription etc?
If your talking about Event Sourcing within a boundary, and having a projection in a boundary, then you'd just replay from the stream directly. If your creating projections outside of your boundary and your doing some conversion from domain event to integration/summary event, then yes, you would need some means to re-publish those events.
What about this concept. We publich internal domain events, and internal consumers generate integration events? It can be 1 domain event with multiple listeners, some of them publish integration events to message broker. What i want to say is data for domain event is a data of internal service, but integration data consists from internal domain event.
You mentioned that transactional, in-process domain eventing isn't your preferred method, and that you'd post a video around what you prefer. After a quick search I'm having trouble finding that video, can you link it if it's already posted? If it's not posted, do you prefer using a message broker for in-boundary domain events?
Yes, ultimately I do. I want isolation in consuming events. Meaning, each consumer handles a message in isolation from other consumers. In-process consuming doesn't provide this. OOTB with a broker/messaging library you'll get built in fault tolerance for retries, DLQ, etc.
Do u mean domain events cannot have their own transaction boundaries? This is bit confusing. Usually aggregates own the domain events and they are supposed to be transactional boundaries themselves. But u say that the publisher and subscriber has to be in one single transaction. Also does domain events need to be always synchronous in memory?
Thanks for the great information as always, I have a question: In event sourcing systems, domain events are the same as integration events, any event you store in the DB should be published to other boundaries, isn't this correct?
In event sourcing, yes your domain events are stored in your event stream as the point of truth. Should you choose to expose those events in the stream to another boundary is a really the point of this video. It really depends on if other boundaries need those explicit domain events and understand them.
From my experience: never ever publish your schema for public. Event sourced events are your aggregate schema and should never be published for public. Thanks me later.
A problem that occurs if you publish your event sourcing events outside is that other processes may try to recreate state over them but will (a) potentially be using different projection logic and (b) has no guarantee they have received all the events and in the correct order, to recreate that state. This means their "understanding" of the state is both out of date and quite likely wrong.
One way around that is to have your "event sourced" system publish any state changes (whenever a projection is run) with an "as of time / sequence number" and naked event notifications (that have the name of the event and what it happened to but no payload) and allow some way for the subscriber to call for the latest state in response to the notification.
