This is a great summary of Wardley Maps and how to run a workshop:

https://pipdecks.com/blogs/workshops/how-to-run-a-wardley-map-workshop

These two concepts work together really well.

Recently I have been experimenting with Json Schema as a way to formally describe an API. It lists all possible inputs that are accepted in a single document. Equivalent schema documents exist for other contracts.

A property test is a way of stating invariants about a system. You write tests that make assertions about the system that are always true for a range of inputs. The testing tool generates an increasingly complex input an runs a series of assertions reporting the simplest case that fails.

If you have a formal input specification the simplest property test you have is I can accept this input without rejecting the message. The contract document gives you a source for the generators.

By creating a generator based upon a specification document allows the tests to keep up with all possible inputs. This is the closest that you can get to a formal proof for system correctness without requiring a single typesystem (which in a distributed system may be impossible).

Here is the starting point:

https://github.com/chriseyre2000/livebooks/blob/main/wardleymap.livemd

Here is an issue in mermaid to add wardley maps to Mermaid: https://github.com/mermaid-js/mermaid/issues/1661

I am going to have a look at seeing if it would be easier to use Kino to put online wardley maps into a livebook or to implement in mermaid.

This tool is great:

https://onlinewardleymaps.com/

However it is not very collaborative.

I am wondering if it would be possible to recreate it in an elixir livebook?

Let’s start to show the amazing power of livebooks without even touching custom code.

First install livebook from this site: https://livebook.dev/

This provides a host to run a livebook.

Start a new livebook

Paste in the following url then hit enter:

https://github.com/chriseyre2000/livebooks/blob/main/EventStorming.livemd

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.

Command-w – closes current tab

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:

• https://www.sciencedirect.com/science/article/pii/S0164121221000674
• https://www.researchgate.net/publication/315637858_The_dark_side_of_event_sourcing_Managing_data_conversion
• https://resources.sei.cmu.edu/asset_files/Presentation/2017_017_001_497589.pdf
  
  There are other possible sources of inspiration:
• Avro
• Protobuf

Avro and Protobuf are wire protocol schemas.

For avro, here I am quoting from: https://docs.oracle.com/cd/E26161_02/html/GettingStartedGuide/schemaevolution.html

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.

I have built a great command for working with releases:

 gh alias set --shell pending 'git log $(gh release list -L 1 | cut -f 1)..@ --pretty="%an - %s" | sort '

This requires you to have `gh` installed along with git, cut and sort.

If you have a specific branch that is meteged into that used for releases this identifies the people whos commits will form part of the next release!