Motivation
Domain-Driven Design has good ideas: aggregates that protect invariants, events that record what happened, reactions that describe what happens next. It also has a reputation for ceremony.
Accord keeps the ideas and drops the ceremony.
What Accord gives you
- A small, explicit API. You define business rules with ordinary classes or functions. No base repositories, no buses to configure, no decorators.
- Failures as values. A business refusal like
InsufficientFundsis a tagged value, not an exception. Operations return[value, null]or[null, error], so the compiler reminds you to look at the error. See Tuples, not throws. - One commit boundary. A successful command saves the new state, the emitted events, and a receipt together. A rejection or exception discards the working copy.
- Reactions that rebuild. Views and projections fold events and can replay history. Policies react to new events only. See Events and delivery.
- Optional everything else. The core has no runtime dependencies. SQLite persistence and Effect integration are separate entry points you import only when you need them.
The building blocks
| Primitive | What it is for |
|---|---|
aggregate | State plus the methods that change it and emit events |
event, rejection | Tagged, schema-validated facts and refusals |
vo | Value objects with validation and domain methods |
view | Read models folded from events |
policy | "When X happens, do Y" |
projection | Replayable writes to another store |
service, external | Typed dependencies and adapters |
workflow | Checkpointed steps with compensation (in memory) |
model, wire | Register everything and get a typed runtime |
api | Expose selected commands and views over HTTP |
story | Scenario tests |
When not to use it (yet)
Accord v0.1 is an in-process runtime. There's no background scheduler, no distributed workflow engine, and no automatic migrations. If you need those today, read Limits of v0.1 first.