# Architecture principles whose scope is module

> 38 records

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

## 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.
- [Runtime Discovery](https://banes-lab.com/records/architecture/runtime-discovery.md): A mechanism that finds the available handlers, plugins or services at startup by matching a naming convention, a file pattern or metadata, and registers each one it finds in place of a hand-written list.
- [Dynamic Binding](https://banes-lab.com/records/architecture/dynamic-binding.md): A mechanism that selects the implementation behind an interface at runtime, from configuration or a registry, so the choice is made at bootstrap or first use rather than fixed in code.
- [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.
- [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md): The degree to which a public interface keeps its signatures and meaning across releases.
- [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.
- [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.
- [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.
- [Correctness](https://banes-lab.com/records/architecture/correctness.md): The degree to which the behavior of code matches its specification.
- [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.
- [Testability](https://banes-lab.com/records/architecture/testability.md): The degree to which code can be tested in isolation, with its dependencies, time and randomness supplied by the test.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [Manifest-Based Design](https://banes-lab.com/records/architecture/manifest-based-design.md): A design pattern that loads modules or plugins from a validated manifest listing each entry, version and dependency.
- [Mediator Pattern](https://banes-lab.com/records/architecture/mediator-pattern.md): A design pattern that routes the interactions between a set of objects through one coordinating object.
- [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.
- [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.
- [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.
- [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.
- [Registry Pattern](https://banes-lab.com/records/architecture/registry-pattern.md): A design pattern that replaces a conditional over kinds with a keyed table that each kind registers itself into.
- [Type Safety](https://banes-lab.com/records/architecture/type-safety.md): A mechanism that has the compiler reject operations on values of the wrong type before the code runs.
- [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.
- [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.
- [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.