# Architecture principles whose type is principle

> 81 records

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

## Entries

- [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.
- [Causality](https://banes-lab.com/records/architecture/causality.md): A design rule that every effect records the event that caused it, so its order can be reasoned about.
- [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.
- [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md): A design rule that every boundary declares the shape and meaning of what crosses it in a typed contract.
- [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.
- [Decentralization](https://banes-lab.com/records/architecture/decentralization.md): A design rule that decisions and runtime control sit with the teams and services that own them, joined by contracts.
- [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.
- [Referential Transparency](https://banes-lab.com/records/architecture/referential-transparency.md): A design rule that an expression can be replaced by its value without changing the program's behavior.
- [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.
- [Platform Independence](https://banes-lab.com/records/architecture/platform-independence.md): A design rule that portable layers reach the operating system and vendor services only through abstractions.
- [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.
- [Configuration Externalization](https://banes-lab.com/records/architecture/configuration-externalization.md): A design rule that environment-specific values are read from validated external configuration at startup.
- [Single Responsibility Principle (SRP)](https://banes-lab.com/records/architecture/single-responsibility.md): A design rule that a class or module has one reason to change, because it serves one responsibility.
- [Separation of Concerns](https://banes-lab.com/records/architecture/separation-of-concerns.md): A design rule that parsing, business logic, persistence and presentation each live in their own part of the code.
- [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.
- [Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md): A design rule that an object's state is changed only through its own operations, which keep its invariants.
- [Information Hiding](https://banes-lab.com/records/architecture/information-hiding.md): A design rule that a module exposes an interface and keeps the implementation decisions behind it private.
- [Abstraction](https://banes-lab.com/records/architecture/abstraction.md): A design rule that a concept is expressed by what it does for the code that uses it, and the detail of how it does it stays out of that expression.
- [Modularity](https://banes-lab.com/records/architecture/modularity.md): A design rule that a system is divided into cohesive modules with explicit boundaries and few dependencies between them.
- [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.
- [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.
- [Autonomy](https://banes-lab.com/records/architecture/autonomy.md): A design rule that a service or team owns its data and decisions, so it alone writes its data and others reach or change it only through its published API or events.
- [Interface Segregation Principle (ISP)](https://banes-lab.com/records/architecture/interface-segregation.md): A design rule that a client depends on an interface holding only the methods it uses.
- [Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md): A design rule that high-level policy and low-level detail both depend on an abstraction owned by the policy.
- [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.
- [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md): A design rule that a subtype can replace its base type anywhere, because it keeps the base type's preconditions, postconditions and invariants.
- [Asynchronous Communication](https://banes-lab.com/records/architecture/asynchronous-communication.md): A design rule that work the caller does not need at once is sent as a message, so the caller does not wait on it.
- [Defensive Programming](https://banes-lab.com/records/architecture/defensive-programming.md): A design rule that code checks its inputs and assumptions before acting on them, and reports a violation as an explicit error.
- [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.
- [Fail Safe](https://banes-lab.com/records/architecture/fail-safe.md): A design rule that a failing operation leaves the system in the state that causes the least harm.
- [Fail Secure](https://banes-lab.com/records/architecture/fail-secure.md): A design rule that an authentication or policy failure denies access.
- [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.
- [Robustness Principle](https://banes-lab.com/records/architecture/robustness-principle.md): A design rule that a component is strict in what it sends and tolerant of harmless variation in what it receives.
- [Error Handling](https://banes-lab.com/records/architecture/error-handling.md): A design rule that every error is either handled with its context kept, or propagated as a typed error the caller must handle.
- [Standardization](https://banes-lab.com/records/architecture/standardization.md): A design rule that one format, tool or pattern is chosen for each recurring concern and applied everywhere it occurs.
- [Self-Describing Architecture](https://banes-lab.com/records/architecture/self-describing-architecture.md): A design rule that each module declares its name, version, capabilities and requirements in metadata that tools and the runtime can read.
- [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.
- [Self-Describing Structures](https://banes-lab.com/records/architecture/self-describing-structures.md): A design rule that a data structure carries its own type tags and field names, so a reader can interpret it without outside knowledge.
- [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.
- [Convention over Configuration](https://banes-lab.com/records/architecture/convention-over-configuration.md): A design rule that a framework infers settings from stable naming and placement conventions, and explicit configuration covers only the exceptions.
- [Code as Data](https://banes-lab.com/records/architecture/code-as-data.md): A design rule that logic to be generated or transformed is held as a typed data structure, such as a syntax tree, that tools can inspect and rewrite.
- [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.
- [Algorithmic Efficiency](https://banes-lab.com/records/architecture/algorithmic-efficiency.md): A design rule that an algorithm and its data structures are chosen for how their cost grows with input size.
- [Single-Pass Processing](https://banes-lab.com/records/architecture/single-pass-processing.md): A design rule that large input is read once, with every result it feeds computed in that one pass.
- [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.
- [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.
- [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.
- [Single Source of Truth](https://banes-lab.com/records/architecture/single-source-of-truth.md): A design rule that each fact, rule or configuration value has one owning definition, and every other value is derived from it.
- [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.
- [Security by Design](https://banes-lab.com/records/architecture/security-by-design.md): A design rule that threats are modeled and controls built into every component from its first design.
- [Defense in Depth](https://banes-lab.com/records/architecture/defense-in-depth.md): A design rule that several independent security controls protect each asset, so one failed control does not expose it.
- [Least Privilege](https://banes-lab.com/records/architecture/least-privilege.md): A design rule that each user, service and process holds only the permissions its task needs.
- [Secure by Default](https://banes-lab.com/records/architecture/secure-by-default.md): A design rule that every setting ships in its most restrictive safe state, and weakening one requires an explicit opt-in.
- [Attack Surface Reduction](https://banes-lab.com/records/architecture/attack-surface-reduction.md): A design rule that endpoints, ports, features and permissions nothing uses are removed or disabled.
- [Privacy by Design](https://banes-lab.com/records/architecture/privacy-by-design.md): A design rule that privacy protection is part of a system's design from its first version, covering which personal data it collects, how long it keeps it, who can see it and what its defaults expose.
- [Governance](https://banes-lab.com/records/architecture/governance.md): A design rule that architecture decisions are held to stated policies and standards, through review and automated gates.
- [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.
- [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.
- [Independent Lifetime Axes](https://banes-lab.com/records/architecture/independent-lifetime-axes.md): A design rule that a surface's lifetime is declared on three independent axes, retention, mutability and removal authority, each taking a value from a closed set, so no single word stands for all three.
- [Write Scope and Read Population](https://banes-lab.com/records/architecture/write-scope-and-read-population.md): A design rule that a run declares the paths it writes and publishes the set it read as two declarations, because collision is decided by the first and a published result's validity by the second.
- [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.
- [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.
- [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.
- [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.
- [Closed Vocabulary](https://banes-lab.com/records/architecture/closed-vocabulary.md): A design rule that every word in a name slot comes from a declared list, and a new word enters the list only by an approved edit.
- [Declared Jurisdiction](https://banes-lab.com/records/architecture/declared-jurisdiction.md): A design rule that a naming gate reads from one declaration the roots it governs, the containers and buckets under each, the classes of file exempt from the grammar, and the trees another system authors or resolves by name, which are exempted once and never governed.
- [One Concern Per File](https://banes-lab.com/records/architecture/one-concern-per-file.md): A design rule that each file plays exactly one declared role, and a file that plays two is split.
- [Narrowest Concern](https://banes-lab.com/records/architecture/narrowest-concern.md): A design rule that a file is classified under the narrowest declared role that describes it accurately.
- [Agnostic-First Vocabulary](https://banes-lab.com/records/architecture/agnostic-first-vocabulary.md): A design rule that a domain-specific role word is admitted only where no domain-neutral role already covers it.
- [Collision Consolidation](https://banes-lab.com/records/architecture/collision-consolidation.md): A design rule that a filename already held by another file is first read as a sign that both files do the same job, and a variant is added only after the code shows that their jobs differ.
- [Conformance at Creation](https://banes-lab.com/records/architecture/conformance-at-creation.md): A design rule that a file created under a governed root is named and placed correctly when it is first written, so no conversion queue accumulates behind new work.
- [Registry-Held Order](https://banes-lab.com/records/architecture/registry-held-order.md): A design rule that load or execution order is held by an import list or a registry, so a filename carries no numeric prefix the grammar would have to parse.
- [Idempotency](https://banes-lab.com/records/architecture/idempotency.md): A design rule that repeating an operation with the same input has the same effect as running it once.
- [Atomicity](https://banes-lab.com/records/architecture/atomicity.md): A design rule that the steps of a state change either all take effect or none do.
- [State Isolation](https://banes-lab.com/records/architecture/state-isolation.md): A design rule that each piece of mutable state belongs to one unit of concurrent execution, so no two units that run at the same time can write it.
- [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.