← Graph

Decider Pattern

concept 9 connections

Functional domain-logic pattern Mateusz Nowak uses to implement Event-Modeled systems. Three pure functions compose the domain: decide(command, state) → events (guards invariants and produces business events), evolve(state, event) → state (applies an event to the state, used for aggregates and read models), and react(event) → command (glue between modules reacting to one event with one or more commands, optionally holding internal state or delegating to a saga for long-running processes). Persistence-agnostic: with 'events → evolve → state → decide → events' you get event sourcing; with 'state → decide → events → evolve → state' you get snapshot/CRUD-style storage. Pairs naturally with given/when/then specifications that translate one-to-one to tests — boilerplate easy to delegate to LLMs.

category
pattern
about
Decider Pattern concept
Implements domain logic with the decide/evolve/react decider functions.
about
Decider Pattern concept
The talk explains the decider pattern in detail.
about
Decider Pattern concept
Sourced's Decider class implements decide/evolve over state and events.
about
Decider Pattern concept
Directly asks about deciders.
person Mateusz Nowak
recommends
Decider Pattern concept
Recommends the decider pattern (decide/evolve/react) for persistence-agnostic domain logic.
concept Decider Pattern
related_to
CQRS concept
Decider composition naturally implements CQRS with command-side decide and query-side evolve.
concept Decider Pattern
related_to
Event Sourcing concept
With events→evolve→state→decide→events the decider pattern yields an event-sourced implementation.
tool decide_rb
related_to
Decider Pattern concept
decide_rb implements the decider pattern in Ruby.
project Sourced
related_to
Decider Pattern concept
Sourced's Decider class implements decide/evolve/react.

Provenance

Read by
2 extractions