You now have a local copy of my mermaid starter for Event Storming.
Yes livebooks allow you to open sample pages that happen to be sitting on a website.
If you click on the edit button that gives you the ability to see the source used to create this. How over the main image and hit +Block and you can add another diagram block and copy and edit the key that I created.
Theoretically these can be edited collaberatively.
This is a collection of thoughts on this big topic. If you are working on an event sourced system it will need to cope with changes to the structure of events over time.
Here is some of the literature that I have found on this topic:
These are the modifications you can safely perform to your schema without any concerns:
A field with a default value is added.
A field that was previously defined with a default value is removed.
A field’s doc attribute is changed, added or removed.
A field’s order attribute is changed, added or removed.
A field’s default value is added, or changed.
Field or type aliases are added, or removed.
A non-union type may be changed to a union that contains only the original type, or vice-versa.
Beyond these kind of changes, there are unsafe changes that you can do which will either cause the schema to be rejected when you attempt to add it to the store, or which can be performed so long as you are careful about how you go about upgrading clients which use the schema. These type of issues are identified when you try to modify (evolve) schema that is currently enabled in the store. See Changing Schema for details.
Avro tends to be used with centralised registries. This is both a benefit for consistency and.a constraint for rapid change.
Protobuf is slightly more flexible. Given that the underlying storage is determined by ids it is the practice to change an id when the meaning of a field changes. It is entirely possible to have two protobuf definition files that are compatible yet don’t share any field names. This is great for translations across bounded contexts. Protobuf permits a slight read/write disparity. Just because a field is required on the write side it may be optional or omitted on the read side.
– Build the Dockerfile (and possibly test locally)
The next steps involve getting the docker image to a registry that Kubernetes can see. One this has happened we need to create a kubernetes deployment.