Enforcing domain events don't change at compile time
JAmes Atwill
Allard Buijze
--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
JAmes Atwill
On Thursday, November 21, 2013 11:02:41 AM UTC-8, Allard Buijze wrote:
what about simply making all the fields final? I tell my teams to do that, but we don't use a tool to enforce it.Or do you mean something else?
Kyle Cordes
On Nov 22, 2013 6:24 PM, "JAmes Atwill" <jat...@linuxstuff.org> wrote:
>
> Something else. Lets say I've created an event, committed it, released and deployed my system into production. Now, another developer comes along, and as part of a refactoring, accidentally makes changes to my event, rendering it incompatible with the version in production, then commits it.
>
> We could definitely write some easily tooling to catch this, but before we do, I wanted to see if anyone else had done something similar.
>
> Does that make sense?
The last time I worked on a system at scale which relied on serialization and deserialization across versions, we added tests to our test suite to verify that old data would still deserialize. That implicitly checks the schema.
Kyle
Allard Buijze
--
Réda Housni Alaoui
Siamak Haschemi
maybe a look at traditional tool for database migration helps.
If you take Luqibase (a tool to have database DDL changes as code in the verison control system, and a binary/maven-plugin to apply those changes to databases), it stores a md5 hash for every changeset-file in a special luquibase-metadata database-table.
When luquibase is executed against a db, luquibase checks that older changefiles' md5 hash has not been changed. It simply stops if a develoer accidentially modified an already applied changeset.
Coming to events, one could write a script which stores the md5 hashes somewhere (could be another git/svn repo, a database, or even in the event-source-file itself). Then you have another script which is executed automatically (jenkins/hudson/team-city/pre-push-hook/...) abd checks the md5 hashes.
A complete other alternative is a Schema Storage like Confluence Avro Storage for Kafka (https://github.com/confluentinc/schema-registry). Your Events are your Schema, and changes to them could be tracked in such a system. Don't get me wrong, the Avro Storage is not for you, the concept could be.
In general, I miss for my own projects an automated solution for Event-Schema documentation, and automatic schema version checks. If you look at the Http-Api/REST world, they have Swagger and other solutions which try to address reflective access to user defined API/Schema.
I might loose a little bit the topic, but I wanted to share my thoughts.
Cheers
Siamak
Patrick Haas
- A "[Aggregate]EventSerializationTest" per aggregate
- For each FooEvent there's a @Test testFooEvent(){} test case
- The test has been simplified to a single line of code: testSerialization(new FooEvent("a","b",...));
- The testSerialization method performs a number of validations, using the object and the JUnit test metdata, e.g. current test method name
- Serialize the event using Jackson (our choice for the event serializer)
- Deserialize the event using Jackson, to confirm the deserialization annotations
- Compare the old and new files to each other, using XStream -- a framework that can xml-serialize virtually any object, which gives us an independent reflection-based confirmation that the two objects are the same
- Compare the serialized JSON to a file on disk (e.g. src/test/resources/events/aggregate/FooEvent.json)
- The file name is automatically discovered based on the test method name
- The JSON is reformatted for comparison to make it readable, e.g. Jackson's "withDefaultPrettyPrint.." configuration
- A final test verifies that every non-abstract event has a serialization test
- It uses component scanning (spring) to find all classes in a specified package matching a name (".*Event") and not abstract
- It uses reflection on the current test to discover all @Test methods, and uses the naming convention to decide which event is covered by the test
- It does a final comparison of the found events and the discovered tests. If there are events without tests, it fails the test.
- Warnings when new events are added, but the serialization has not been documented yet
- Warnings when events (or value objects contained within an event) are changed in ways affecting the serialization
- Example JSON for all of our events (and commands), which is a great reference when writing e.g. upcasters (for events) or developing a javascript UI (commands)
