Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

ConceptChapter I · Fundamentals · Building block 6 of 7

Complexity

Technical complexity arises from rules and concepts of the problem. Technical complexity arises through mechanisms, dependencies and operating models of the solution.

By Michael Meierhoff · Meierhoff Systems

  1. Domain-levelComes from rules of business.
  2. TechnicalComes from the chosen solution.
  3. PriceEvery situation costs test and operation.

Context

Why this is important

Not every difficulty belongs to business. Every technical situation must be tested, observed and operated; anyone who considers it unavoidable pays this price without need. The conscious limitation deals with building block simplicity.

This building block explains the origin and effect of complexity. For the deliberate limitation of additional mechanisms, see Simplicity and Complexity Budget.

Shop example · Growing situations

What can I do with order B-1042 Everything is happening?

Discount rules and reservation periods are part of the shop business. Every technical decision adds situations that the business did not demand. Turn it on and see how the order B-1042 It becomes more complex.

This is how you read the picture

  1. Domain-level The green tiles, such as “reservation expired” – they always remain.
  2. Technical The orange tiles that only appear with a decision.
  3. Price The counter: from 5 up to 13 Situations.

5 Situations which: Order B-1042 control must be: Make a technical decision on this.

  • Domain-levelOpenOrder is created, payment is pending.
  • Domain-levelbezahltPayment is confirmed.
  • Domain-levelshippedThe show is on its way.
  • Domain-levelReservation expiredThe deadline for the stock has passed.
  • Domain-levelVoucher does not applyThe discount rule excludes a product.
Green: business situations that the shop must always master. Orange: Situations that arise only through a technical decision. They are not forbidden, but a price that must be worth it.

Benefits & limitations

Helps if:

  • Changes regularly affect a surprising number of building blocks or teams.
  • A design introduces new layers, services or coordination mechanisms and requires a cost-benefit assessment.

Boundaries

  • Domain scenarios remain relevant in every design; a compact structure must keep them visible. Check them against the Functional Requirements.
  • Additional technical scenarios have a cost that must be justified by demonstrated benefits; see Simplicity.
  • The number of situations is an indication, not a measure; coupling shows how changes spread along the paths.

In practice

  1. Identify interactions. Record states, dependencies and coordination for a relevant flow. The result makes visible where delays, common changes or error consequences arise.
  2. Identify the source of complexity. Separate business rules from decisions introduced by technology or organisation. Consider Coupling when a change propagates across many building blocks.
  3. Weigh additional mechanisms against their benefits. Identify the specific benefit and ongoing operational and change costs of each addition. Simplicity helps align a design with demonstrated needs.
Read the detailed explanation

Domain complexity arises from the rules, states and exceptions of the problem domain. Technical complexity comes from additional dependencies, distribution, abstractions and operational mechanisms. Architecture can organise necessary distinctions visibly and limit interactions introduced by the design itself. Simplicity considers the appropriate scope of a design; Coupling describes an important source of technical dependencies.

The effort needed to understand a system depends on how easily a team can find rules, trace changes and isolate faults. Code size and the number of building blocks provide useful indicators when considered alongside these working practices. Each additional mechanism needs a clear benefit, an owner responsible for maintenance and a way to verify its effects.

Fred Brooks calls the complexity inherent in the problem essential complexity and the complexity introduced by the chosen solution accidental complexity.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which situations are added by “creating an asynchronous account”?

    View the solution with justification

    “Invoice is still missing” and “Invoice order duplicately served”. Both arise only through the asynchronous creation, not through the business.

  2. ApplyingTransferred to a new situation

    The shop introduces partial deliveries: an order can come in two packages. Green or orange tile?

    View the solution with justification

    Green. Partial delivery is a business rule and remains, whether the shop is built as a monolith or with services. It belongs in the technical model.

  3. EvaluateWeighing an alternative

    Is it worthwhile to operate shipping as your own service, even though three new situations arise?

    View the solution with justification

    Only with a proven need, for example, if your own team has to independently publish and scale the shipment. Without this benefit, the shop pays three additional error pictures for nothing.

Explore further

These building blocks continue the thoughts of this page.

PrinciplesSimplicity & complexity budgetHere you find criteria for an understandable design and the value of additional mechanisms.Opening RequirementsFunctional requirementsFunctional requirements describe the business capabilities a system provides.Opening PrinciplesModule boundariesModule boundaries define which data and capabilities a module owns and which contracts others use to access them.Opening

References

Continue on the learning path

Next in Fundamentals & orientation: Architecture ownership.

7 Building blocks

Continue withArchitecture ownership