# Architecture Principles

> Architecture principles and how to write them, modularity, coupling, cohesion, separation of concerns, information hiding.

## Concepts

- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md): An architecture principle is a short statement of what an organization values. It narrows the options for design decisions without dictating the answer, so teams decide faster and more consistently.
- [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md): An architecture principle is written in four parts: a Name, a Statement, a Rationale and Implications. Together they show the rule, why it helps the business, and what it demands.
- [Complexity Reduction](https://arc.fuet.ch/concepts/principles/complexity-reduction.md): Complexity reduction means keeping a system as simple as its problem allows. Needless complexity makes software harder to understand, change and debug, so architects avoid whatever the problem does not require.
- [Component Design Principles](https://arc.fuet.ch/concepts/principles/component-design-principles.md): Component design principles guide how to build parts of a system so they stay loosely coupled and easy to change. They hide internals, depend on stable interfaces, and keep wiring separate from use.
- [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md): Architecture principles such as simplicity, separation of concerns and low coupling each favor some qualities and cost others. They are guidelines, not absolute rules, so architects weigh them against business context and record the trade-offs.
- [Connect or Disconnect](https://arc.fuet.ch/concepts/principles/connect-or-disconnect.md): Connecting components creates dependencies between them. Disconnecting them avoids that but can hide dependencies. Good design keeps few, narrow, explicit dependencies, and the right amount depends on how much control you have.
- [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md): Continuous Architecture rests on principles that guide design reasoning. The facts here cover four: focus on quality attributes, delay decisions until facts exist, architect for change with small elements, and organize teams after the system design.
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md): Coupling describes how strongly modules depend on each other. Cohesion describes how well the parts inside one module belong together. Low coupling often goes with high cohesion.
- [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md): Design for change means making the parts of a system that are likely to change easy to modify. Apply it only where change is foreseeable, because flexibility costs effort and can make other changes harder.
- [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md): High cohesion means the parts of a module belong together and serve one focused responsibility. A change to that responsibility then stays inside one module. It works best together with low coupling.
- [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md): Incrementality means building and changing an architecture in small steps, with feedback after each step. It replaces designing everything at once, because requirements keep moving and not every issue can be foreseen.
- [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md): Information hiding means splitting a system into modules that each conceal one hard or change-prone design decision. Clients use only the module's interface, so the inside can change without breaking them.
- [Interface Segregation Principle](https://arc.fuet.ch/concepts/principles/interface-segregation-principle.md): The Interface Segregation Principle says code should not depend on methods it does not use. Teams split large interfaces into smaller ones, each fitted to one role.
- [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md): Loose coupling means building blocks depend on each other as little as possible, so a change in one rarely forces a change in another. The right level depends on how much control you have over both sides.
- [Main Sequence (Balance of Abstractness and Instability)](https://arc.fuet.ch/concepts/principles/main-sequence.md): The main sequence is an ideal line on a chart that plots how abstract a software component is against how unstable it is. Components are judged by their distance from that line.
- [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md): Modularity means dividing a system into self-contained building blocks. The quality of the split depends on the criteria used to divide the system, so modularity is a design issue.
- [Open-Closed Principle](https://arc.fuet.ch/concepts/principles/open-closed-principle.md): A building block stays open to new behavior but closed to edits of its existing code. Other parts rely on a fixed interface, and new behavior arrives through new implementations of it.
- [Process Automation Magnifies Efficiency](https://arc.fuet.ch/concepts/principles/process-automation-magnifies-efficiency.md): Automation speeds up whatever process it is given, good or bad. Fix or remove wasteful steps first, then automate. Otherwise software only makes the waste run faster.
- [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md): Architecture principles support one another. Based on the verified facts: high cohesion tends to bring low coupling, and low coupling signals a well-structured system that avoids rigidity.
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md): Separation of concerns means studying one aspect of a problem on its own while staying aware of the others. In software, it means splitting an application by responsibility so the code stays organized and manageable.
- [Shearing Layers](https://arc.fuet.ch/concepts/principles/shearing-layers.md): Shearing Layers means grouping parts of a system that change at similar rates and keeping them apart from faster or slower parts. The boundaries between layers help lasting abstractions emerge.
- [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md): Traceability links requirements to the architecture that serves them. arc42 describes a full form, where every requirement is referenced, and a pragmatic form, where key decisions are explained by their requirements. It advises avoiding the full form when possible.
- [Types of Cohesion](https://arc.fuet.ch/concepts/principles/types-of-cohesion.md): Cohesion describes how well the parts of a module belong together. Seven types exist, from functional (strongest) to coincidental (weakest). Each type names the reason the parts were grouped.
- [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md): Working with principles means writing short rules that tie design decisions to requirements. A good principle has a name, a statement, a rationale and implications. Teams may break one only for a justified reason.