[grandalf]

I was thinking of making CRUD a specific event type that had meaning only in the context of changes to an instance of some schema. Of course, the most interesting events will not be CRUD oriented, but does this mean it's a mistake to include them at all, particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized?

[karmajunkie]

I don't know if I'd be strong enough in my words to call it a "mistake" (there are few absolutes) but its a big stinky code smell, and it likely falls into that bucket of things you're going to regret one day sooner than you realize.

The thing is, DDD isn't easy. You're going to end up with someone on your team at some point that's inexperienced with it, and having a bunch of CRUD events in the schema already is going to entice them to add a few more because its easy and they're already there and oh hey what's a few more amongst friends?

Something else I've learned about this stuff is that because it works best in stable domains, it is also going to work best in domain services that have low code churn. Once you get it right, it tends to stay that way. But if you try to model with non-domain events, you're dramatically increasing the surface area that is subject to churn.

YMMV but I wouldn't do it.

[karmajunkie]

> particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized?

This is also an antipattern, btw—events between bounded contexts should be somewhat limited, and well-defined behaviors when doing so. What you're doing with a scheme like that, sharing CRUD events between external services or systems, breaks all kinds of conceptual and logical encapsulation (in addition to the aforementioned CRUD thing.)

[grandalf]

Why is it an antipattern? What does it make more difficult?

Pattern matching? Creating useful state snapshots? Curious to hear more about your experience.