# Architecture principles whose scope is component

> 24 records

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

## 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.
- [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.
- [High Cohesion](https://banes-lab.com/records/architecture/high-cohesion.md): The degree to which the members of a class or module work on the same data towards the same purpose.
- [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md): The degree to which a module can change without forcing changes in the modules around 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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [Abstract Factory Pattern](https://banes-lab.com/records/architecture/abstract-factory-pattern.md): A design pattern that creates a whole family of related objects through one interface, so the members always match.
- [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.
- [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.
- [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.
- [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.
- [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.