# Architecture principles whose scope is system

> 47 records

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

## 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.
- [Runtime Extensibility](https://banes-lab.com/records/architecture/runtime-extensibility.md): The degree to which new capability can be added to a running system through extension points, without modifying its core.
- [Invariant](https://banes-lab.com/records/architecture/invariant.md): A rule or precondition that holds for an entity or aggregate in every state it can reach.
- [Interoperability](https://banes-lab.com/records/architecture/interoperability.md): The degree to which separate systems exchange data and use it correctly through shared formats and contracts.
- [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.
- [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.
- [Correctness](https://banes-lab.com/records/architecture/correctness.md): The degree to which the behavior of code matches its specification.
- [Verification](https://banes-lab.com/records/architecture/verification.md): The activity of checking that an implementation conforms to its specification.
- [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.
- [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.
- [Event-Driven Architecture](https://banes-lab.com/records/architecture/event-driven-architecture.md): A convention of connecting services through published events, with each consumer reacting independently of the producer.
- [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.
- [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.
- [Fault Tolerance](https://banes-lab.com/records/architecture/fault-tolerance.md): The degree to which a system keeps operating correctly when some of its components fail.
- [Resilience](https://banes-lab.com/records/architecture/resilience.md): The degree to which a system contains failures, stays stable under stress and recovers.
- [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.
- [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.
- [Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md): An approach in which the architecture changes in small increments, each guarded by fitness functions.
- [Greenfield Development](https://banes-lab.com/records/architecture/greenfield-development.md): An abstraction of building a new system with no inherited code, so its boundaries are designed from the current forces.
- [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.
- [Architectural Consistency](https://banes-lab.com/records/architecture/architectural-consistency.md): The degree to which the code follows the system's declared boundaries, layers and dependency rules.
- [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.
- [Model-Driven Architecture](https://banes-lab.com/records/architecture/model-driven-architecture.md): An approach in which a formal model is the source of truth and the implementation is generated from it by transformation rules.
- [Observability](https://banes-lab.com/records/architecture/observability.md): The degree to which a system's internal behavior in production can be inferred from the logs, metrics and traces it emits.
- [Auditability](https://banes-lab.com/records/architecture/auditability.md): The degree to which each sensitive action can be traced afterwards to its actor, target, time and reason.
- [Scalability](https://banes-lab.com/records/architecture/scalability.md): The degree to which a system keeps its throughput and latency as load grows, by adding resources.
- [Throughput](https://banes-lab.com/records/architecture/throughput.md): The rate at which a system completes requests, messages or items, counted per unit of time.
- [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.
- [Optimization](https://banes-lab.com/records/architecture/optimization.md): The activity of changing code or configuration to reduce the cost of a bottleneck that a measurement has located.
- [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.
- [Queuing Theory](https://banes-lab.com/records/architecture/queuing-theory.md): A conceptual representation of a system as queues with arrival and service rates, used to predict waiting time and size capacity.
- [Plugin Architecture](https://banes-lab.com/records/architecture/plugin-architecture.md): A convention of building a small core that discovers and loads plugins through declared extension points.
- [Self-Healing Architecture](https://banes-lab.com/records/architecture/self-healing-architecture.md): The ability of a system to detect a failed component from its health signals and restore it without human action.
- [Chaos Engineering](https://banes-lab.com/records/architecture/chaos-engineering.md): The practice of injecting controlled faults into a running system to test a stated hypothesis about how it recovers.
- [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.
- [Zero Trust Architecture](https://banes-lab.com/records/architecture/zero-trust-architecture.md): A convention of authenticating and authorizing every request on its own identity and context, whatever network it comes from.
- [Threat Modeling](https://banes-lab.com/records/architecture/threat-modeling.md): The activity of listing a flow's assets, trust boundaries and threats, and choosing a mitigation for each threat.
- [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.
- [Compliance](https://banes-lab.com/records/architecture/compliance.md): A rule or precondition that a system implements the controls a regulation or standard requires, and keeps evidence of each one.
- [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.
- [Layered Architecture](https://banes-lab.com/records/architecture/layered-architecture.md): A convention of stacking presentation, application and persistence layers, each calling only the layer below it.
- [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.
- [Microservices](https://banes-lab.com/records/architecture/microservices.md): A convention of splitting a system into services that each own their data and deploy independently.