Skip to content
Software Architecture Guide

arc42 Constraints

Explanation

Section titled “Explanation”

A constraint is any requirement that limits the freedom of architects in their design and implementation decisions. Chapter 2 of arc42 (see arc42 Architecture Documentation Template) collects them in one place.

The reason is simple. Architects should know exactly where they are free to decide and where they must stick to a given limit.

Handling constraints. A team must always deal with a constraint. Some constraints can be negotiated, though. Writing down the background of each one helps readers see which limits are firm and which might move.

Typical groups. If the list grows long, you can split it into three groups:

  • Technical constraints. Limits on the technology to use. The biking2 example requires a Java 8 and Spring Boot showcase. It also requires that the application compiles on Mac OS X, Linux and Windows.
  • Organizational and political constraints. These include standard processes, budget, time and required information flows. The biking2 example requires that source and documentation be published as open source under the Apache 2 License.
  • Conventions. Rules such as programming style and naming conventions.

Typical format. A simple table works well: one column names the constraint, and another explains it and gives its background.

Constraints and other chapters. The related article Architectural Constraint covers how constraints differ from requirements. Decisions the team makes itself belong in the chapter on arc42 Architecture Decisions. The approach built within the limits belongs in Solution Strategy.

Example

Section titled “Example”

A team builds a small web shop. Its constraints table might read:

Constraint Background
Must compile on Linux, Windows and macOS Developers work on all three systems.
Source code published as open source The company wants outside contributors.
Variable names follow the company naming rules Teams share code across projects.

A reader sees at once which choices are already made for the team. Everything not listed is open for design decisions.

Checks

Section titled “Checks”
  • The document lists constraints in one place, with an explanation or background for each.
  • Constraints are grouped into technical, organizational/political and conventions where the list is long.
  • Organizational constraints such as budget, time or processes are recorded.
  • Conventions such as programming style and naming rules are recorded.
  • Each constraint shows whether it may be negotiated.
Section titled “Related”

Sources

Section titled “Sources”