# Architecture principles whose scope is coordination

> 6 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/scope/coordination

## Entries

- [Domain Service](https://banes-lab.com/records/architecture/domain-service.md): A design pattern that places a domain rule spanning several entities in a stateless service named in the domain's language.
- [Leader Election](https://banes-lab.com/records/architecture/leader-election.md): A mechanism that lets a group of nodes agree on one coordinator and replace it when it fails.
- [Choreography](https://banes-lab.com/records/architecture/choreography.md): A mechanism that coordinates a cross-service flow through events, with each service reacting to the previous one's event.
- [Stated Invariant](https://banes-lab.com/records/architecture/stated-invariant.md): A design rule that an invariant a topology relies on is written with its property in a form that could be false, the set it ranges over, the parties it binds and the thing that would object if it stopped holding.
- [Derived Record State](https://banes-lab.com/records/architecture/derived-record-state.md): A design rule that a record's state is a query over the edges it carries, open while its satisfying artifact is unresolved, blocked while a blocker is open and absorbed once the artifact exists, so no party writes a state.
- [Derived Party Count](https://banes-lab.com/records/architecture/derived-party-count.md): A design rule that the number of parties a body of work implies is derived from how the work is partitioned into concerns, so two parties holding one partition reach one count.