Cleaning up UIDs

Making UIDs more consistent and easier to use:

1. Spec tester API now passes NextUid field which contains the next Uid to generate. Implementing code no longer needs to parse past events or persist counter (not all implementations do that).
2. All tests have monotonically incrementing Uids. This will avoid potential conflicts in case implementations store distinct entities only by their uid.

Full Changelog: v1.3.2...v1.4.0

More specs around reservation and fulfilment

This is a minor release with more tests to catch edge cases we've discovered

Full Changelog: v1.3.1...v1.3.2

Introduce Fulfill request and Cancelled event

• Added Fulfill Request - this completes the reservation by removing it from the system and removing related items from the inventory. It comes with Fulfilled event

In reality this is done via a series of "PickItem-Picked" operations, but we don't care that much.

• Added Cancelled event - when reservation is cancelled, "releasing" all locked items. There is no Cancel request. The purpose is to support over-reservation process, where reservation from VIP customer might evict less valuable reservations

switch all IDs from int64 to Guid (string)

In the previous versions, API and specs used sequential int64 as an ID. This created a bias towards event-sourcing implementations that have a monolithic shared state.

In this release we are switching all IDs from int64 to Guid (string) in API and specs.

When your code runs in test mode, it is expected that it will use globally unique ids for all entities (you can use a static singleton for that). For example, first product will get 00000000-0000-0000-0000-000000000001, first location created after it - 00000000-0000-0000-0000-000000000002.

For the sake of brevity, spec output will replace these with:

• "00000000-0000-0000-0000-000000000001" -> UID(1)
• "00000000-0000-0000-0000-000000000002" -> UID(2)

Unique identifiers are represented with a string type in our gRPC proto3 schema. This avoids problems with various platforms and byte orders.

More availability specs

• Added more specs around availability
• Specs are ordered by features (more simple come first)
• bfkata always prints Version and git commit
• Removed Lambda contracts from API

Full Changelog: v1.1.0...v1.2.0

First release of bfkata

This is the very first release to test binary artifacts