# Conflicting Architecture Principles

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

## Explanation

Each design principle pushes a system in one direction. Pushed far enough, it works against another principle.

**Where principles pull apart**

- **Separation of concerns** (see Separation of Concerns) leads to layers and separate projects. Business logic becomes easy to test. The system also gains more parts.
- **Loose coupling** often uses interfaces, so different implementations can be plugged in. The price is extra abstraction.
- **Single responsibility**, taken to its logical endpoint, gives microservices. Microservices bring complexity, overhead and dependency issues.
- **Simplicity** pulls the other way. A complex solution offers more flexibility, but it needs more coordination between components, which can hurt reliability. A simple one may hurt scalability and extensibility.
- **DRY** (don't repeat yourself) can clash with low coupling. Merging code that only looks alike creates a wrong shared piece. Here, duplication can be the better choice.
- **YAGNI** (you aren't gonna need it) warns against building flexibility before it is needed. Early flexibility adds complexity now and pays off only later.

**Over-applying a principle**

Azure guidance warns against both over-engineering and under-engineering. Splitting code into many small functions, for example, makes it harder to understand, test and maintain.

**Principles need context**

Principles are not universal rules. Every design decision should be justified by a business requirement. Teams should not follow trends that may not fit their context.

Constraints are also negotiated. Reaching reliability targets may require compromise between technology and business teams.

**Making the trade-off explicit**

The Architecture Tradeoff Analysis Method (ATAM) shows how quality goals interact and trade off. It identifies risks, sensitivity points and trade-off points. An Architectural Decision Record (ADR) documents a chosen decision with its rationale, trade-offs and consequences.

## Example

A team builds an internal tool for 50 users. One member wants every feature split into its own service, with interfaces everywhere, to keep parts independent. Another wants one simple application. The team notes that the user base is small and the business needs a release in two months. They choose a single application with clear internal layers. They write an ADR that records this choice, the reasons, and the condition under which they would split it later.

## Trade-offs

Following one principle strictly buys one quality and spends another. More separation gives testability but adds components. More simplicity gives easier understanding but may limit scalability and extensibility. No setting satisfies every principle at once. The team has to choose, justify the choice with business needs, and write it down. Writing takes effort, but it keeps the reasoning available later.



## Checks

- Design decisions are justified by a business requirement, not by a principle alone.
- Decisions where principles conflict are recorded with their rationale, trade-offs and consequences.
- Choices such as microservices are justified by fit to context, not by trend.
- Added abstraction (interfaces, extra layers) is tied to a need such as pluggability or testability.

## Related

- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md)
- [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md)
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)

## Sources

- [Architecture strategies for designing for simplicity and efficiency - Microsoft Azure Well-Architected Framework | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/reliability/simplify) — learn.microsoft.com, accessed 2026-11-09
- [Architectural principles - .NET | Microsoft Learn](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles) — learn.microsoft.com, accessed 2026-11-09
- [Yagni](https://martinfowler.com/bliki/Yagni.html) — martinfowler.com, accessed 2026-11-09
- [Architecture Tradeoff Analysis Method® Collection | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/) — sei.cmu.edu, accessed 2026-11-09
- [Architectural Decision Records (ADRs) | Architectural Decision Records](https://adr.github.io/) — adr.github.io, accessed 2026-11-09