Thread by @mathiasverraes

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy I think the naming is sloppy and creates a false dichotomy. (I imagine it exists for historic reasons). The naming suggests that integration events somehow are not messages that convey something has happened in the domain.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy It also suggests that events (wether persisted or not) should not leave the Bounded Context, and instead different events should be created.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy I agree with the reasoning behind that, but I think the conclusion that people usually draw ("Never share domain events") is unnuanced and doesn't consider other forces. In other words, whether or not to share domain events should be a deliberate tradeoff.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy You could share all the context's domain events, or some of them, or translate them, or compose them into new events. And a single context may have multiple API endpoints, so each could have a different strategy for publishing domain events.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy See for example the Explicit Public Events pattern verraes.net/2019/05/patter… and Segregated Event Layers verraes.net/2019/05/patter…

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy Discussions on Domain Events vs Integration Events often seem to ignore the needs of the consuming context. Do they need to react to some key events from another context? Then Summary Events are a good option verraes.net/2019/05/patter…

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy But if they need to consume lots of events, for example to do a Projection, analytics, ML, ... and especially if you don't know in advance what they will need, then offering a Completeness Guarantee is very powerful verraes.net/2019/05/patter…

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy Another problem I have with the "vs" in the Domain Events vs Integration Events framing is that events are not the only integration tool. Mainly Queries and Commands are essential types of integration messages that offer different tradeoffs.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy Roughly, the use of Events, Queries, and Commands, shift responsibilities between Bounded Contexts. Who owns the data, who owns the interpretation, who knows the business rules.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy A single endpoint could offer a combination of Commands, Queries, and Events; a single Bounded Context could offer different endpoints that use different strategies.

@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy For example, (in DDD terms), an Open Host that offers a small set of Queries and Commands, and a second endpoint that offers much more detailed Events.