Setting Up the Project

Starting EventSourcingDB#

ArchitectureKit stores its events in EventSourcingDB. Start it with the following command. On the first start, Docker downloads the image:

docker run -it -p 3000:3000 \
  thenativeweb/eventsourcingdb run \
  --api-token=secret \
  --data-directory-temporary \
  --http-enabled \
  --https-enabled=false

This starts EventSourcingDB on port 3000, with the API token secret, a temporary data directory that is cleaned up on shutdown, and unencrypted HTTP.

Keep EventSourcingDB running for the whole tutorial. Every step builds on the events that the previous steps have written, and since the data directory is temporary, stopping EventSourcingDB removes all of them.

To check that EventSourcingDB is ready, open a second terminal and send a ping:

curl http://localhost:3000/api/v2/system/ping

The response looks like this, with the exception of the id and time fields, which differ on every ping:

{"type":"event","data":{"specversion":"1.0","id":"01a1d3b6-7fad-7ed1-8b60-a173dafdec9b","source":"https://www.eventsourcingdb.io","type":"io.eventsourcingdb.api.ping-received","subject":"/api/v2/system/ping","time":"2026-11-13T07:01:55.245955675Z","datacontenttype":"application/json","data":{"message":"My God, it's full of stars."}}}

Creating a Package#

In the second terminal, create a package for the library with Cargo, and change into its directory. Then add ArchitectureKit, serde, which writes and reads the data of events as JSON, and Tokio, which runs the asynchronous code of ArchitectureKit:

cargo new library
cd library
cargo add architecturekit
cargo add serde --features derive
cargo add tokio --features macros,rt-multi-thread

ArchitectureKit connects to EventSourcingDB through the client SDK for Rust, which it brings along as architecturekit::eventsourcingdb, so that the versions of the two always fit. So you do not add the client SDK yourself.

Planning the Files#

The package library holds two crates: a library crate with the code of the library, and a binary crate, the program that runs it. Cargo compiles the tests in the directory tests as programs of their own, which can use a library crate, but not a binary crate, so the code lives in the library crate. All files are in the library directory:

• src/lib.rs lists the modules of the library crate, which the following files hold.
• src/events.rs and src/book.rs hold the events and the state of a book.
• src/store.rs connects to EventSourcingDB.
• src/commands.rs and src/deciders.rs hold the commands and the decisions on them.
• src/catalog.rs and src/queries.rs hold the view and the queries that read it.
• src/requests.rs maps HTTP requests to commands and queries.
• src/responses.rs maps the items of the catalog to HTTP responses.
• tests/deciders.rs tests the decisions.

The following steps add these files one by one, and add their modules to src/lib.rs. The file src/main.rs, which cargo new has created, holds the program. It runs what the current step is about, so every step replaces it, and it uses the library crate by the name of the package, as in library::store::new_store.