# Architecture principles whose category is Core Modular Design

> 16 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/category/core-modular-design

## Entries

- [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.
- [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.
- [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.