WowDomain Model as a Service

Write only the domain model, and get a system you can run in production.

Only the domain model

Commands decide, events evolve the state, and the compiler binds both at build time: no reflection and no infrastructure code.

The log is the bus

One append is the only write. Everything else reads the log from its own checkpoint, so no committed fact is lost on the way.

One contract

The Manifest describes the service once. HTTP routes, OpenAPI, the TypeScript client and the views are derived from it.

Read models replay

The latest state of every aggregate is queryable as it is, and every read model can be rebuilt from the start of the log.

Failures are data

A handler that keeps failing parks the one aggregate it failed on. Nothing is skipped, and nothing else stops.

PostgreSQL or MongoDB

Both are first-class log backends. Kafka carries what crosses contexts, and ClickHouse serves the datasets.

What you write, and what you get

A command function of the quickstart's bank account decides a withdrawal against the current state:

kotlin

@OnCommand(produces = [Withdrawn::class])
fun onCommand(command: Withdraw): Decision = when {
    command.amount <= 0 ->
        Decision.reject(Rejections.INVALID_AMOUNT, "${command.amount} is not positive.")

    command.amount > state.balance ->
        Decision.reject(Rejections.INSUFFICIENT_BALANCE, "The balance is ${state.balance}.")

    else -> Decision.events(Withdrawn(command.amount))
}

Its test says it in the same terms, given events, when a command, expect events and state, with no server:

kotlin

@Test
fun `a withdrawal the balance does not cover is rejected`() = aggregateSpec(model, id = "alice") {
    given(AccountOpened("Alice"), Deposited(100))
    whenCommand(Withdraw(150)) { expectRejected(Account.Rejections.INSUFFICIENT_BALANCE) }
    whenCommand(Withdraw(30)) {
        expectEvents(Withdrawn(30))
        expectState { balance.assert().isEqualTo(70) }
    }
}

From that model, without more code, the service gets an HTTP route for each command, a state read and snapshot queries, an OpenAPI document, a Manifest from which wow-generator generates a typed TypeScript client, and its rejections as application/problem+json with their error codes.

Start where your job is

You want to	Start with
Decide whether Wow fits your system	How Wow works, then the glossary
Write a service	Quick start, then deciding and evolving
Call a service from a TypeScript front end	TypeScript client
Run services in production	Identity, tenancy and access, then subscriptions, failures and replay
Analyze the data	Read models, then the workbench

Recognition

Wow received the KaiCode’26 Excellent Award. The official results highlighted its modular DDD/CQRS design, disciplined multi-reviewer code review, Testcontainers-based integration testing, enforced test coverage thresholds, Detekt static analysis, bilingual documentation, and long history of semantically versioned releases on Maven Central.