Service-Oriented Architecture

Audience: Bitwarden engineers and AI agents building, extracting, or reviewing a service.

This section is the living standard for how Bitwarden's services are built and how they relate to one another: what a service owns, how a boundary is crossed, what travels on a call, and what every service publishes. The service model was adopted in ADR-0035, and the pages here evolve by pull request without superseding that decision.

Key patterns

Services

Service boundaries derive from data ownership. Every resource has exactly one owning service, and consumers cross a boundary through the client that service publishes.

See Services for the full standard.

Command Query Separation (CQS)

We use the CQS pattern to break up large service classes into smaller, focused commands and queries. This results in classes with fewer interdependencies that are easier to change and test.

See Command Query Separation for details.

Model separation of concerns

API contracts (request/response models) are kept separate from internal data models. This allows APIs to evolve independently from internal data structures and business logic.

See Model separation of concerns for details.