Skip to content
Software Architecture Guide

Solution Strategy

Explanation

Section titled “Explanation”

The solution strategy is section 4 of an arc42 document (see arc42 Architecture Documentation Template). It gives a short summary and explanation of the fundamental decisions that shape the architecture.

What belongs in it

  • Decisions about the top-level decomposition of the system. This means how the system is split at the highest level. An architectural pattern or a design pattern is a typical example (see Architectural Pattern vs. Design Pattern).
  • Decisions on how to reach the key quality goals.
  • Relevant organizational decisions. Examples are choosing a development process or handing certain tasks to third parties.

Justify the decisions

Do not only state what you decided. Explain why. Base the reasoning on the problem statement, the quality goals, and the key constraints. These live in chapters 1 and 2 (see arc42 Introduction and Goals and arc42 Constraints). Link to them.

Tie approaches to quality

Describe each solution approach in the context of a quality requirement. A reader should see which goal an approach serves.

Keep it short

Brevity is a stated requirement for this section. A compact list of keywords works well. Refer onward to concepts, views, or code instead of detailing them here.

Example

Section titled “Example”

A small web shop might list its strategy like this:

  • Top-level split: a layered structure, chosen so the team can change one part without touching the others.
  • Quality goal “easy to change”: hide details behind clear interfaces. Details are in the cross-cutting concepts chapter.
  • Organizational: an external provider runs payment processing.

Each line is a short keyword phrase, names its reason, and points elsewhere for detail.

Trade-offs

Section titled “Trade-offs”

The section must stay short, so it cannot carry full reasoning. Put the details in other chapters and link to them. The cost is that readers must follow links to get the whole picture.

Checks

Section titled “Checks”
  • The section is short and compact, for example a keyword list, and refers onward instead of giving details.
  • The section states the top-level decomposition decision, such as an architectural or design pattern.
  • Each key quality goal has a solution approach described in the context of that goal.
  • Decisions are justified from the problem statement, quality goals, and key constraints, with links to chapters 1 and 2.
  • Relevant organizational decisions, such as the development process or work given to third parties, are included.
Section titled “Related”

Sources

Section titled “Sources”