I always like the architectural way of thinking you have - there's always trade-offs to be understood and it's about the sympathetic treatment of the people, process and technology. In a highly complex environment, with legacy monoliths, one key way we try to loosely couple is through the canonical data model integration pattern (Hohpe & Woolf). 2nd key point for me is that data semantics evolve differently than business events - data models mature (less change over time) but business events (should) change frequently. These two things makes me look to split data synchronization events (including what data changed and what prior data was) from business events (just business context info).
Interesting. Adding additional fields at contract layer, creates an explicit dependency on the contract. I'm not sure whether this is really a good idea (?). But at least to me, it sounds new because anecdotally, components manipulate the events. Also, this technique necessiates having a robust contract management and contract versioning. Please correct me if I'm wrong.
Usually you distinguish between breaking and non-breaking changes to contracts in API's (whether something like REST or Async like events doesn't matter). In short: adding fields is non-breaking if you implement it right on the consumer side. Changing fields can be non-breaking - for instance in REST, you consider going from number to string _in_the_request_ to be non-breaking, since numbers can be contained in a string - but not vice versa. It's is not dissimilar to database changes. Dropping a column can break someones query where that column is explicitly stated. Adding a column - shouldn't - break anything as it is not (supposed) to be part of anything. "Supposed" because there are do's and dont's, but unfortunately people sometimes do the dont's - like SELECT * and reference the columns by index - and so if you've added a column in the middle of something, the indexing get's screwed up. Shouldn't have broken anything - but it did break poor code...
But if the publisher cared more and more about the needs of consumers, the event will gradually turn into a full-contract with less cohesion. I think we need to take the force of which business workflows are critical and need low latency to decide when to add or remove a field in the event model.
Thanks Mark Richard, your explanations are excellent
I always like the architectural way of thinking you have - there's always trade-offs to be understood and it's about the sympathetic treatment of the people, process and technology. In a highly complex environment, with legacy monoliths, one key way we try to loosely couple is through the canonical data model integration pattern (Hohpe & Woolf). 2nd key point for me is that data semantics evolve differently than business events - data models mature (less change over time) but business events (should) change frequently. These two things makes me look to split data synchronization events (including what data changed and what prior data was) from business events (just business context info).
Lesson 165 - Event-Driven Architecture > ruclips.net/video/P0aUV4ixvBQ/видео.html
Interesting. Adding additional fields at contract layer, creates an explicit dependency on the contract. I'm not sure whether this is really a good idea (?). But at least to me, it sounds new because anecdotally, components manipulate the events.
Also, this technique necessiates having a robust contract management and contract versioning. Please correct me if I'm wrong.
Usually you distinguish between breaking and non-breaking changes to contracts in API's (whether something like REST or Async like events doesn't matter).
In short: adding fields is non-breaking if you implement it right on the consumer side.
Changing fields can be non-breaking - for instance in REST, you consider going from number to string _in_the_request_ to be non-breaking, since numbers can be contained in a string - but not vice versa.
It's is not dissimilar to database changes. Dropping a column can break someones query where that column is explicitly stated. Adding a column - shouldn't - break anything as it is not (supposed) to be part of anything. "Supposed" because there are do's and dont's, but unfortunately people sometimes do the dont's - like SELECT * and reference the columns by index - and so if you've added a column in the middle of something, the indexing get's screwed up. Shouldn't have broken anything - but it did break poor code...
But if the publisher cared more and more about the needs of consumers, the event will gradually turn into a full-contract with less cohesion. I think we need to take the force of which business workflows are critical and need low latency to decide when to add or remove a field in the event model.