Skip to content
Software Architecture Guide

Crosscutting Concept

Explanation

Section titled “Explanation”

Some decisions do not belong to one part of a system. They apply in many parts at once. Logging and security are typical examples. arc42 calls these crosscutting concepts. It describes them as practices, patterns, regulations, or solution ideas that often span several building blocks. (A building block is a part of the system, such as a module or component.)

Where they live. arc42 section 8 holds them. The arc42 overview describes this section as covering overarching, often very technical topics, such as technology choices and recurring patterns. The section grows as the team decides on more concepts.

Why they matter. Concepts give the architecture conceptual integrity. That means the system is consistent and homogeneous.

Who reads them. Many concepts are highly technical, so they are written for developers. Sometimes source code with a short explanation is enough. Long prose is not always needed.

Choosing topics. Treat section 8 as a checklist at first. Work iteratively and drop topics that do not matter for your system. To keep the section from becoming a melting pot, remove irrelevant concepts. Then group the rest.

Links to other chapters.

  • The solution strategy (see the article Solution Strategy) stays brief. Section 8 explains the how and why of approaches. References connect the two.
  • Building blocks should show which concepts they apply. One way is to tag a block with a concept name as a stereotype. A block can apply several concepts.

Related idea. Outside arc42, a cross-cutting concern is an aspect of a program that affects several modules. Logging and authentication are examples.

Example

Section titled “Example”

A team builds an online shop with three building blocks: Orders, Payments, and Catalog. All three need logging. Instead of explaining logging three times, the team writes one logging concept in section 8. It holds a short rule and a code snippet. Each of the three blocks is tagged with the concept name and points to it. The strategy chapter mentions logging in one line and links to the concept.

Trade-offs

Section titled “Trade-offs”

Writing a concept once keeps the system consistent. It also takes effort to choose which topics belong in section 8. If the team keeps irrelevant topics, the section becomes a melting pot. Source code with brief notes is quick to write. Some concepts may still need more explanation than code alone gives.

One concept applied in several building blocks

Diagram source 
flowchart LR
  C["Concept: Logging (section 8)"]
  A[Orders] --> C
  B[Payments] --> C
  D[Catalog] --> C

Checks

Section titled “Checks”
  • Section 8 contains only concepts that are relevant to the system, and they are grouped.
  • Building blocks name the crosscutting concepts they apply, for example through a stereotype tag.
  • The solution strategy stays brief and references section 8 for the how and why of approaches.
  • Technical concepts are written for developers, with source code and short explanations where that suffices.
Section titled “Related”

Sources

Section titled “Sources”