For my next project I’m trying to find out if there has been any attempts already at creating a generic JSON domain event format. To compare, for REST APIs I am very happy to use JSON:API to structure any documents, as clients can understand what the parts are without necessarily understanding the domain specific parts. Similarly I would like to have a JSON domain event format, where an event consumer can be generic enough to understand what is going on structurally without necessarily understanding the domain specifics. This would allow event consumers to perform database projections, for example, without having to understand each individual domain event semantically.
As an example, here’s what I came up with myself as a starting point. Each event would be in DDD terms, so always works on entities, with aggregate information as metadata (type+id), and value objects as potentially complex JSON object attributes. JSON would look something like:
{
name: “CreatedComment”,
created: {type:“Comment”,id:“12345”},
attributes: {“title”:“Nice!”,“body”:“Great stuff!”},
addedRelationships:[
{name:“PostComments”,type:“Post”,id:“somepostid”}
]
}
Essentially a diff format, so focusing on what has changed, but with a domain event perspective. This way a generic event consumer would be able to project these in databases, especially schema-less versions like Neo4j or ElasticSearch, without having to necessarily understand any of the domain specific data.
Quick thought ; own opinion don’t let that discourage you
Attempting to make a generic interchange format with the goal of not having to understand the payload & type for projection is at odds with the goal of having domain specific event .
Also projecting stream of events is also use case specific
Even using graphQL requires to know & understand the data being queried.
HTML was successful because it standardized the structure, while letting the website specific data be variable. Same with any other successful format that is not just plain text/JSON/XML. The event is domain specific, the format doesn’t have to be. You mention GraphQL, which is a great example, because the format is defined by a specification so that tooling can work with any valid query, and yet the specifics are usecase dependent.
What I’m interested in here is a format for sharing domain events as essentially diffs of what the change is in the domain. That is what the event expresses in my experience.
CloudEvents, from what I can tell, is more about defining the metadata about an event. What I’m specifically interested in is the payload format.
{ name: “”, attributes: [ ] , addedRelationships[] } this kind of makes me think you’re thinking in terms of relational models ?
This kind of structure might help automate a list / details type of projection in a RDBMS , but not one that would create a document in KV store , Elastic search as you mentioned
How would such structure allow to create projections that are cross streams ( cross “post” in the sample you gave)
For me the minimal “structure” of an event is
Type
Data ( could be any format)
MetaData (could be any format )
Stream owning the event + position in that stream
Position in the stream the event is read from
Side note: I’ve seen people just sending their events as-is into Elastic Search with great success.
I’m using DDD terms: aggregate, entity, value object, and relationships between entities. If that is all that exists, then it should be possible to have a standardized format to describe changes in DDD models. As it so happens, my database of choice is Neo4j (where I already have an automated mapping of the format I used as example), and OpenSearch which I can dump these events into without any processing at all.
For the “structure” you are describing, to be clear, the ONLY thing I care about here is the data, and specifically that it is explicitly not in “any format”, but in a specific format where the domain data is the only variable.
And I am also specifically not asking for opinions on how to create such a format, but rather if anyone has already done such a format, tried it, and has experience with it.
I’m not sure how many other ways to say the same thing as the opening post, but there it is.