[DDD/CQRS] Distinguishing between internal and external events

[Thomas Oellrich]

Hi,

we're in the middle of doing our first DDD/CQRS application and one point of contention came up. My colleagues insist that we should distinguish between internal domain events only consumed by the bounded context which raises them itself (mainly in order to populate view models) and external domain events consumed by other bounded contexts. The reason being that it would be more likely and easier to change the internal events whereas the external events would form more of a stable API. A separate layer would be responsible for translating all internal events into external events. Seems like a lot of work to me. What do you guys think? Is anybody doing it that way?

Thanks,

Thomas

[Jimmy Bogard]

Yes, for a few reasons:

1) It's easier to partition out messages of internal vs. external - I can give out only what I am allowing others to see

2) When I give others my messages, versioning concerns start to come into play. I want to limit my exposure there.

3) Often you might need to include additional information that isn't on your events (i.e., things I might pull from a ViewModel)

It's work - but worth it, as these boundary concerns often have very different forces for change than what are essentially implementation details of my model. Think of it this way - if you were doing a relational model, you wouldn't hand over your connection string to connect straight to your data model, would you?

[Thomas Oellrich]

Thanks for your answer, makes sense. Do you still publish your internal events via a message broker/bus or do you simply use some kind of in-memory observer pattern for these kind of events?

Regarding versioning, that would be feasible, I guess, if you used a data format that can be forward and backward compatible, such as Protobuf of JSON (or even XML w/o schema). I've actually just watched a new interview with Eric Evans where he was asked what he thinks about using JSON as a data contract for loosly coupled systems:

http://www.infoq.com/interviews/Technology-Influences-DDD

He seems to like it if it's inside a single bounded context, outside not so much. Maybe that could be an answer. Reuse internal events inside the same bounded context, but create external events for other bounded contexts. Now, if only I really understood what the difference between a bounded context and a business component was ;)

[Ben Fischer]

Would I create two different event versions for a single event if this event has to be accessible both internal and external?

For example, AccountRegisteredEvent. BC1 (where this event originates) needs it for resource generation purposes, BC2 for accounting purposes.

If BC2 does not need more properties in this event then the BC1 put into it, could I reuse the BC1 event from BC2 or do I always create a new one?

Thanks,

Ben

[Greg Young]

write a projection that converts internal to external. you knowing who
your subscribers are and how they want to use information is horribly
broken.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Thomas Oellrich]

Not knowing who your subscribers are and what information they want, how would you define what your external events looked like?

[@yreynhout]

Which begs the question why waste your time splitting up your events into internal and external events? The answer is only a projection (or multiple) away ...

On Saturday, October 6, 2012 7:45:54 PM UTC+2, Thomas Oellrich wrote:

Not knowing who your subscribers are and what information they want, how would you define what your external events looked like?

On 6 October 2012 17:19, Greg Young <> wrote:

write a projection that converts internal to external. you knowing who
your subscribers are and how they want to use information is horribly
broken.

[Thomas Oellrich]

Projection into what? Other kinds of events? Who would be responsible for that? The event-producer? An anti-corruption layer? The event-consumer?

[@yreynhout]

Projection into those unknown and widely varying external events, ... or wait, lets just skip those and project into the required, aggregated format. If the downstream format is unknown or can't "steer" upstream in any way, why waste your time with external vs internal?

[João Bragança]

+1. I've seen lots of talk about internal vs external events but
haven't seen a practical example.

How often are your event schemas changing? Are you just adding fields?
or dropping and / or renaming too? I think if you can stick to just
adding fields, the other side can simply not deserialize what it
doesn't understand.

[Ben Fischer]

I'm sorry, but that confused me even more ;) 

Could someone sum that up a little bit?

What would be the more efficient way, projection into shared format (ACL?) or internal event published outside BC?

[João Bragança]

The OP was discussing this in the context of the API changing.

It depends. Is the team responsible for BC1 changing fields on the
events a lot (exampla retunsa: last week the event was tracking the
order id and the skus + quantities that were ordered; this week they
added sales tax per item; next week they will add the discount
amount)? If so then BC2's team can't 'trust' what's coming out of
there and they should consider an ACL. But maybe the fields BC3 cares
about (e.g. the order's aggregate id and the total amount of the
order) have been stable, so they *don't* need an ACL.

In either case I think the last thing you want is a one size fits all solution.