# Architecture principles whose severity is recommended

> 96 records

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

## Entries

- [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.
- [Context Mapping](https://banes-lab.com/records/architecture/context-mapping.md): The activity of recording how bounded contexts relate, including which one is upstream and how their models translate.
- [Anti-Corruption Layer](https://banes-lab.com/records/architecture/anti-corruption-layer.md): A design pattern that translates an external system's model into the local domain's terms at the boundary.
- [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.
- [Dynamic Dispatch](https://banes-lab.com/records/architecture/dynamic-dispatch.md): A mechanism that chooses which operation runs from the receiver or a keyed table at runtime, replacing a conditional over kinds.
- [Causal Dependency](https://banes-lab.com/records/architecture/causal-dependency.md): A conceptual representation of one step or event that cannot proceed until another has happened.
- [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md): A design rule that every operation states the preconditions it needs, the postconditions it guarantees and the invariants it keeps.
- [Interface-Based Design](https://banes-lab.com/records/architecture/interface-based-design.md): A design rule that a module depends on interfaces, and the implementation behind each one is supplied from outside.
- [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md): A design rule that a boundary's contract is written and agreed before the implementation behind it.
- [Postconditions](https://banes-lab.com/records/architecture/postconditions.md): A rule or precondition that an operation's result and resulting state must satisfy when it returns.
- [Forward Compatibility](https://banes-lab.com/records/architecture/forward-compatibility.md): A rule or precondition that an older reader accepts data from a newer writer by ignoring the fields it does not know rather than failing on them.
- [Uniform Interface](https://banes-lab.com/records/architecture/uniform-interface.md): A rule or precondition that every resource in an API uses the same verbs, response shapes and error format.
- [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md): A rule or precondition that a provider verifies each change against the expectations its consumers have recorded.
- [Centralized Authentication](https://banes-lab.com/records/architecture/centralized-authentication.md): A design pattern that verifies identity once, at a shared identity provider, and passes the result to each service.
- [Centralized Logging](https://banes-lab.com/records/architecture/centralized-logging.md): A design pattern that ships structured logs from every instance to one aggregated store.
- [Determinism](https://banes-lab.com/records/architecture/determinism.md): A design rule that the same inputs and state always produce the same result, with time and randomness passed in as inputs.
- [Predictability](https://banes-lab.com/records/architecture/predictability.md): The degree to which a caller can foresee what an operation does from its interface and contract.
- [Pure Functions](https://banes-lab.com/records/architecture/pure-functions.md): A technique for writing logic as functions whose result depends only on their arguments and which have no side effects.
- [Immutability](https://banes-lab.com/records/architecture/immutability.md): A design rule that a value is never changed after it is created, and a change produces a new value.
- [Reproducibility](https://banes-lab.com/records/architecture/reproducibility.md): The degree to which a build, test or training run gives the same output from the same pinned inputs on another machine.
- [Specification-Based Testing](https://banes-lab.com/records/architecture/specification-based-testing.md): The activity of deriving tests from a specification's stated behavior, independently of how the code implements it.
- [Property-Based Testing](https://banes-lab.com/records/architecture/property-based-testing.md): The activity of checking that a stated property holds for many generated inputs, and shrinking each failure to a minimal counterexample.
- [Environment Parity](https://banes-lab.com/records/architecture/environment-parity.md): A design rule that development, test, staging and production run the same build, differing only in configuration.
- [Protocol Independence](https://banes-lab.com/records/architecture/protocol-independence.md): A design rule that domain logic is written against ports, and each transport protocol reaches it through its own adapter.
- [Composability](https://banes-lab.com/records/architecture/composability.md): A design rule that parts share compatible interfaces and carry no hidden side effects, so they can be combined into larger parts.
- [Composition Over Inheritance](https://banes-lab.com/records/architecture/composition-over-inheritance.md): A design rule that behavior is reused by holding and delegating to another object instead of extending its class.
- [Reusability](https://banes-lab.com/records/architecture/reusability.md): The degree to which a function or module can serve a new caller without change, because it carries no context of its first one.
- [Replaceability](https://banes-lab.com/records/architecture/replaceability.md): The degree to which a component can be swapped for another implementation of its interface without editing its callers.
- [Interchangeability](https://banes-lab.com/records/architecture/interchangeability.md): The degree to which several implementations conform to one contract closely enough to be selected at runtime.
- [Independence](https://banes-lab.com/records/architecture/independence.md): A design rule that a module can be tested and deployed without the modules around it being present or released.
- [Open/Closed Principle (OCP)](https://banes-lab.com/records/architecture/open-closed.md): A design rule that a module gains new behavior by adding code at an extension point, leaving its existing code unchanged.
- [Polymorphism](https://banes-lab.com/records/architecture/polymorphism.md): A mechanism that lets one interface have several implementations, with the implementation chosen by the object that receives the call.
- [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.
- [Integration Events](https://banes-lab.com/records/architecture/integration-events.md): A design pattern that publishes a versioned public event, mapped from an internal domain event, for consumers outside the service.
- [Outbox Pattern](https://banes-lab.com/records/architecture/outbox-pattern.md): A design pattern that writes an outgoing message in the same local transaction as the state change, and a relay publishes it afterwards.
- [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md): A design rule that invalid input or state stops the operation at the point it is detected, with an explicit error.
- [Graceful Degradation](https://banes-lab.com/records/architecture/graceful-degradation.md): A design rule that the failure of an optional dependency removes only the feature it serves, and the rest of the system keeps working.
- [Error Boundaries](https://banes-lab.com/records/architecture/error-boundaries.md): A design pattern that catches failures at a component boundary, so a failing part renders or returns an error while the rest keeps running.
- [Assessment](https://banes-lab.com/records/architecture/assessment.md): The activity of evaluating a codebase or architecture against stated criteria, using collected evidence.
- [Architecture Review](https://banes-lab.com/records/architecture/architecture-review.md): The activity of examining a structural change against the architecture's criteria and recorded decisions before it is accepted.
- [Design Review](https://banes-lab.com/records/architecture/design-review.md): The activity of checking a component or feature design for contracts, failure modes and testability before it is built.
- [Impact Analysis](https://banes-lab.com/records/architecture/impact-analysis.md): The activity of tracing a change through the dependency graph to find every consumer it affects.
- [Fitness Functions](https://banes-lab.com/records/architecture/fitness-functions.md): A mechanism that turns an architecture rule into an executable check the pipeline runs on every change.
- [Quality Attributes](https://banes-lab.com/records/architecture/quality-attributes.md): A conceptual representation of the non-functional properties a system must meet, each stated as a measurable scenario.
- [Architecture Decision Records (ADR)](https://banes-lab.com/records/architecture/architecture-decision-records.md): A formal definition of one architecture decision, recording its context, the choice made and its consequences.
- [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.
- [Pattern Consistency](https://banes-lab.com/records/architecture/pattern-consistency.md): The degree to which one kind of problem is solved with the same pattern throughout a codebase.
- [Self-Describing API](https://banes-lab.com/records/architecture/self-describing-api.md): A design rule that an API publishes machine-readable descriptions of its operations, payloads and errors.
- [Declarative Configuration](https://banes-lab.com/records/architecture/declarative-configuration.md): A design rule that a system's settings are declared as validated data, and the system configures itself from that data.
- [Capability Declaration](https://banes-lab.com/records/architecture/capability-declaration.md): A mechanism by which a plugin or service lists the operations it supports, so callers test the list instead of probing for methods.
- [Causation ID](https://banes-lab.com/records/architecture/causation-id.md): A mechanism that stamps each event with the identifier of the event that caused it.
- [Dashboards](https://banes-lab.com/records/architecture/dashboards.md): Descriptive data about a system's key signals, arranged as panels that show health and trends at a glance.
- [Strategy Pattern](https://banes-lab.com/records/architecture/strategy-pattern.md): A design pattern that puts each interchangeable algorithm behind one interface, so the caller selects behavior by passing an object.
- [Observer Pattern](https://banes-lab.com/records/architecture/observer-pattern.md): A design pattern in which a subject publishes events to subscribers it does not know by name.
- [Command Pattern](https://banes-lab.com/records/architecture/command-pattern.md): A design pattern that wraps a request in an object, so it can be queued, deferred or undone.
- [State Pattern](https://banes-lab.com/records/architecture/state-pattern.md): A design pattern that gives each state of an object its own class, so behavior and legal transitions change with the state.
- [Chain of Responsibility Pattern](https://banes-lab.com/records/architecture/chain-of-responsibility-pattern.md): A design pattern that passes a request along an ordered list of handlers until one of them handles it.
- [Finite State Machine](https://banes-lab.com/records/architecture/finite-state-machine.md): A conceptual representation of behavior as a closed set of states and the events that move between them.
- [Factory Pattern](https://banes-lab.com/records/architecture/factory-pattern.md): A design pattern that moves the construction of an object and its defaults into one function or object.
- [Builder Pattern](https://banes-lab.com/records/architecture/builder-pattern.md): A design pattern that assembles a complex object step by step through named calls and validates it when it is built.
- [Facade Pattern](https://banes-lab.com/records/architecture/facade-pattern.md): A design pattern that gives a subsystem one simple entry point, so callers do not depend on its parts.
- [Composite Pattern](https://banes-lab.com/records/architecture/composite-pattern.md): A design pattern that gives leaves and groups one interface, so a tree is traversed without checking which kind each node is.
- [Statelessness](https://banes-lab.com/records/architecture/statelessness.md): A design rule that a handler keeps no request state between calls, so any instance can serve any request.
- [Performance Engineering](https://banes-lab.com/records/architecture/performance-engineering.md): The practice of setting performance budgets, measuring against a representative workload and changing code only where a measurement points.
- [Profiling](https://banes-lab.com/records/architecture/profiling.md): A technique for measuring where a running program spends its time and memory under a representative workload.
- [Benchmarking](https://banes-lab.com/records/architecture/benchmarking.md): The activity of timing a fixed workload repeatedly in a controlled environment, so results can be compared across changes.
- [Bottleneck Analysis](https://banes-lab.com/records/architecture/bottleneck-analysis.md): The activity of finding the stage that limits a system's overall throughput or latency, from traces and profiles.
- [Pipeline Architecture](https://banes-lab.com/records/architecture/pipeline-architecture.md): A design pattern that splits processing into ordered stages, each with a declared input and output contract.
- [Stateless Processing](https://banes-lab.com/records/architecture/stateless-processing.md): A design rule that a processor derives each result only from its input and explicitly passed context.
- [Extension Points](https://banes-lab.com/records/architecture/extension-points.md): A mechanism that exposes named hooks or interfaces where new behavior can be added without editing the core.
- [Inversion of Control (IoC)](https://banes-lab.com/records/architecture/inversion-of-control.md): A design rule that a framework or composition root owns object creation and control flow, and application code supplies the parts it calls.
- [Dependency Injection](https://banes-lab.com/records/architecture/dependency-injection.md): A design pattern that passes an object its dependencies from outside, usually through its constructor.
- [Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md): A formal definition of one concept's shape, published once and used by every API, message and store that carries the concept.
- [Canonicalization](https://banes-lab.com/records/architecture/canonicalization.md): A technique for converting equivalent values to one normal form before they are compared, stored or checked.
- [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.
- [Intent-Revealing Interface](https://banes-lab.com/records/architecture/intent-revealing-interface.md): A design rule that an operation's name and parameters state what it does for the caller.
- [Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md): A design rule that an operation behaves the way its name and its conventions lead a caller to expect.
- [Database Normalization](https://banes-lab.com/records/architecture/database-normalization.md): A technique for decomposing tables by their functional dependencies into normal forms, so no column depends on anything but its key.
- [Policy as Code](https://banes-lab.com/records/architecture/policy-as-code.md): A mechanism that expresses policies as machine-readable rules which a pipeline or policy engine evaluates automatically.
- [Ports and Adapters Architecture](https://banes-lab.com/records/architecture/ports-and-adapters-architecture.md): A convention of placing every external dependency behind a port the application owns, implemented by an adapter outside it.
- [Hexagonal Architecture](https://banes-lab.com/records/architecture/hexagonal-architecture.md): A convention of keeping a domain core free of framework and data types, with every input and output reached through ports.
- [Clean Architecture](https://banes-lab.com/records/architecture/clean-architecture.md): A convention of concentric layers in which source dependencies point only inward, towards the use cases and entities.
- [Component-Based Architecture](https://banes-lab.com/records/architecture/component-based-architecture.md): A convention of building a system from components that declare what they export and what they require.
- [Package by Feature](https://banes-lab.com/records/architecture/package-by-feature.md): A design rule that code is grouped by the feature it serves, so one change stays inside one package.
- [Pipes and Filters](https://banes-lab.com/records/architecture/pipes-and-filters.md): A convention of processing data through independent stages that share one input and output interface.
- [Section Lifetime Divergence](https://banes-lab.com/records/architecture/section-lifetime-divergence.md): A rule or precondition that a file states a default lifetime and each section declares only the axes on which it differs, since the narrower unit is the more constrained one.
- [Read-Time Join](https://banes-lab.com/records/architecture/read-time-join.md): A mechanism that lets a caller whose question a live declared scope already covers read that run's published result and its standing, writing nothing, so it cannot deadlock, be orphaned or need cleanup.
- [One-Sided Liveness](https://banes-lab.com/records/architecture/one-sided-liveness.md): A design rule that a process's absence proves it is dead while its presence proves nothing, so liveness is derived once, from the witness first and from a generous window only where the witness cannot decide.
- [Reversible Channel Encoding](https://banes-lab.com/records/architecture/reversible-channel-encoding.md): A rule or precondition that a channel name is a total and invertible encoding of the scope it belongs to, with an alphabet that excludes the separator, so a retention check can read the scope back out of the name.
- [Declare-Before-Read Order](https://banes-lab.com/records/architecture/declare-before-read-order.md): A mechanism that orders two simultaneous starters without a lock by writing each entry before reading the set, with the start stamp and then the party identity breaking a tie.
- [Period-Decided Disposition](https://banes-lab.com/records/architecture/period-decided-disposition.md): A design rule that a duplicate is first counted by its distinguished copies and then read by the period of each derivation edge, so a periodic copy owes a comparator and a one-shot copy is a record whose source is repaired instead.
- [State-Arity Limit](https://banes-lab.com/records/architecture/state-arity-limit.md): A rule or precondition that a property relating two states of content, such as growing but never shrinking, is enforced only by a mechanism holding both readings, in the layer that already spans runs.
- [Carrier and Payload Split](https://banes-lab.com/records/architecture/carrier-and-payload-split.md): A design rule that a surface read through a tool types the fields a mechanism joins on and leaves the fields only a reader consumes as prose, deciding the line per field.
- [Joinable Mandated Field](https://banes-lab.com/records/architecture/joinable-mandated-field.md): A rule or precondition that a mandated field takes a value from a closed set or an identifier, or declares that it is written for readers, so a governed surface never looks measured on a property nothing can read.
- [Unit of Work Pattern](https://banes-lab.com/records/architecture/unit-of-work-pattern.md): A design pattern that collects the changes of one use case and commits them together in a single transaction.
- [Controlled Side Effects](https://banes-lab.com/records/architecture/controlled-side-effects.md): A design rule that mutation, I/O and persistence happen at declared boundaries, around a core of pure functions.