# Working with Principles

**In short:** 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.

## Explanation

An architecture principle is a rule that guides design decisions. Its purpose is to link those decisions to requirements. It makes sure some part of a design choice meets some part of the requirements. That link lets you trace each principle back to the requirement behind it.

Principles also help people decide consistently. They clarify priorities and constraints, so different people reach compatible choices. For background, see the article *Architecture Principle*.

**What makes a principle good**

Good principles are constructive, reasoned, well-articulated, testable and significant. "Testable" matters most in reviews. You should be able to check whether a design follows the principle.

**How to write one**

A common template has four parts:

- **Name:** It captures the essence of the rule and is easy to remember.
- **Statement:** It is brief and direct. It conveys the basic rule.
- **Rationale:** It gives the benefits of following the rule, in business terms.
- **Implications:** They list what the business and IT must do to comply.

The article *Architecture Principle Structure* covers this template in more detail.

**Principles as developer guidelines**

One example repository pairs developer guidelines with implications. It links them to Architectural Decision Records (ADRs), which are short records of significant design choices. One guideline there says to use ADRs to document significant choices and their rationale.

**Breaking a principle**

Teams will occasionally break a principle. That is allowed. The reason must be justifiable.

## Example

A shop has a requirement that customers can order at any hour. The team writes a principle named "Keep ordering available". The statement is one sentence. The rationale says lost orders mean lost revenue. The implications say IT must plan for failures and the business must agree on support hours. Later, one team wants to skip the rule for a small internal tool. They write down why, so the exception can be reviewed.

## Trade-offs

Principles give consistency, but they only help if people can follow and check them. A vague principle cannot be tested. A principle with no link to a requirement is hard to defend. Allowing justified exceptions keeps principles practical. It also means exceptions need to be recorded and reviewed.

A principle links requirements to design decisions and guidelines.

```mermaid
flowchart LR
  R[Requirement] --> P[Principle]
  P --> D[Design decision]
  P --> G[Developer guideline]
  D --> A[ADR]
```

## Checks

- Each principle can be traced to a requirement it supports.
- Each principle has a memorable name and a brief, direct statement.
- Each principle gives a rationale in business terms.
- Each principle lists implications for business and IT.
- Every case where a principle was broken has a justification.

## Related

- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md)
- [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md)
- [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md)
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md)
- [TOGAF](https://arc.fuet.ch/concepts/enterprise-architecture/togaf.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)

## Sources

- [Harnessing the Power of Architectural Design Principles - InfoQ](https://www.infoq.com/articles/architectural-design-principles/) — infoq.com, accessed 2026-11-09
- [Architectural Principles - CIO Wiki](https://cio-wiki.org/wiki/Architectural_Principles) — cio-wiki.org, accessed 2026-11-09
- [Principles and Guidelines | Sunny Calculator Add-On](https://docs.sunnycalc.griesser.com/architecture/05-principles-and-guidelines/) — docs.sunnycalc.griesser.com, accessed 2026-11-09