# Architecture principles whose scope is domain

> 18 records

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

## Entries

- [Domain-Driven Design (DDD)](https://banes-lab.com/records/architecture/domain-driven-design.md): A convention of modeling software on the business domain's own language, split into bounded contexts with a domain model in each.
- [Domain Model](https://banes-lab.com/records/architecture/domain-model.md): A formal definition of the business concepts, rules and invariants of one context, written as types with behavior.
- [Bounded Context](https://banes-lab.com/records/architecture/bounded-context.md): A rule or precondition that each domain model holds inside one explicit boundary, where its terms have one meaning.
- [Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md): A design rule that each module declares its public interface and owner, and other modules reach it only through that interface.
- [Aggregate](https://banes-lab.com/records/architecture/aggregate.md): A design pattern that groups entities under one root, which is the only entry point and keeps the group's invariants.
- [Value Object](https://banes-lab.com/records/architecture/value-object.md): A design pattern that models a domain value as an immutable, self-validating object compared by its attributes.
- [Entity](https://banes-lab.com/records/architecture/entity.md): A design pattern that models a domain object by a stable identity, which stays the same while its attributes change.
- [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.
- [Semantic Contracts](https://banes-lab.com/records/architecture/semantic-contracts.md): A rule or precondition that each term and value at a boundary has one agreed meaning, beyond its type.
- [Do Not Repeat Yourself (DRY)](https://banes-lab.com/records/architecture/duplicate-code.md): A design rule that each piece of logic, constant or schema has one source in the code, and every other use refers to it.
- [Event Sourcing](https://banes-lab.com/records/architecture/event-sourcing.md): A design pattern that stores state as the sequence of events that produced it and rebuilds current state by replaying them.
- [Domain Events](https://banes-lab.com/records/architecture/domain-events.md): A design pattern that records each significant change in the domain as an event named in the domain's language.
- [First-Principles Design](https://banes-lab.com/records/architecture/first-principles-design.md): An approach in which a design is derived from the problem's forces and invariants before any known pattern is chosen.
- [Domain-Specific Language (DSL)](https://banes-lab.com/records/architecture/domain-specific-language.md): A design pattern that expresses a domain's rules or workflows in a small language with a defined grammar and a validator.
- [Language-Oriented Programming](https://banes-lab.com/records/architecture/language-oriented-programming.md): An approach in which each problem domain gets its own language, with a type checker and an evaluator, and solutions are written in it.
- [Canonical Model](https://banes-lab.com/records/architecture/canonical-model.md): A design rule that a concept has one authoritative representation, and every other representation is translated to and from it.
- [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md): The degree to which one name carries one meaning across the code, the schemas and the documentation.
- [Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md): The practice of using the domain's own terms, agreed with its experts, in conversation, documentation and code alike.