What decision determines whether the checkout is waiting for the bill, and what is it in the shop?

The communication decision: The shop works asynchronously, the PDF follows later. It determines response time, error behavior and intermediate status.

The shop should offer payment by bill and by card. Is “strategy patterns for payment types in the payment module” an architectural decision? And the renaming of a variable in it?

Yes, the strategy pattern: it shapes the contract between order and payment and any future payment method. The renaming no: It only works in one place; the team decides in the code.

The team also wants to keep the product search in SQL to run only one database. Weigh in.

This is due to less operational expenditure with a technology. In contrast, weaker full-text queries talk about descriptions and categories. The decision depends on how important search quality is as a quality goal.

ConceptChapter I · Fundamentals · Building block 4 of 7

Architecture decision

An architectural decision answers a formative design question with comprehensible reasons. It also keeps the consequences of the chosen option visible.

By Michael Meierhoff · Meierhoff Systems

Design questionA question that concerns several parts.
OptionsAt least two real alternatives.
ScopeWhat binds the election later.

Context

Why this is important

Decisions with great scope are expensive to change later on. Without a joint justification, the team discusses them again or meets them unnoticed in the code. How you hold it shows the building block ADR.

This building block explains which design issues have architectural scope. The ADR shows how you document such a decision.

At a glance · From the question to the recorded decision

A question is evaluated with options and criteria; the decision and consequences are recorded as ADR.

Shop example · Mapping

The shop's decision map

The shop team has made five decisions that go far beyond a single module: from system style to communication and data storage to patterns that multiple modules rely on.

This is how you read the picture

Design question The draft question column, such as “Does the checkout wait for the bill?”
Options The Options column, such as Modular Monolith · Microservices.
Scope The column Why Scope: Delivery, Error Behavior, Consistency, and Common Transitions.

The shop's decision map
Species	Design question	Options	Decision in the shop	Why is the scope
System style	How is the shop built and delivered?	Modular monolith · Microservices	Modular monolith	Determines delivery, operation and team tailoring.
Communication	Is the checkout waiting for the bill?	synchronous · asynchronous	Asynchronous: The PDF will follow later.	Determines response time, error behavior and intermediate status.
Data management	Where are orders, where is the product search?	SQL · NoSQL · Search index	SQL for orders, search index for products	Determines consistency, query options and operation.
Architectural patterns	Do order processing and customer service overview share a model?	One model · CQRS	CQRS with its own reading overview	Brings two models, synchronization and delayed display.
Broad-acting design sample	How are order status and permitted transitions regulated?	scattered queries · State patterns	State patterns in the order module	Payment, shipping and invoice rely on the same transitions.

Each line binds several modules, teams or quality goals and is expensive to change later. No architectural decision is against what a variable is called or how a method works inside; that is what the team decides in the code.

Benefits & limitations

Helps if:

A choice affects several building blocks, teams or quality goals, and its consequences need to remain understandable.
Several plausible options meet different priorities and must be compared against common criteria.

Boundaries

Not every choice is an architectural decision: the team handles renaming and method internals in the code without a separate decision record.
A decision applies to the context in which it was made; reassess the Architectural Drivers when goals or load change.
A decision remains an intention until someone checks its consequences; Fitness Functions make properties that can be checked automatically observable.

In practice

State the question and the available choices. Describe the design question and identify binding constraints. The result should allow at least two feasible options.
Compare the consequences of each option. Assess benefits, effort, risks and affected quality goals against the same criteria. Trade-off Analysis makes the competing goals that shape the comparison explicit.
Record the decision and a trigger for reassessment. Name the selected option, the reasons for it and an event that should trigger another review. An Architecture Decision Record preserves this information for future readers.

Read the detailed explanation

A decision becomes architecturally significant when its consequences affect several building blocks, teams or quality goals and changing it would require substantial effort. Typical examples include architectural style, communication, data storage and patterns on which several modules rely; variable names and the internals of individual methods fall outside this scope. The decision establishes which option to pursue under the current goals. Drivers and constraints narrow the solution space; Trade-off Analysis compares competing consequences.

The decision itself is the choice made. An Architecture Decision Record subsequently documents the question, context, alternatives considered and consequences so that the reasoning remains understandable. New evidence may trigger reassessment. The existing decision can then be replaced or adjusted; its documented rationale saves the team from having to reconstruct it from the code.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What decision determines whether the checkout is waiting for the bill, and what is it in the shop?
View the solution with justification
The communication decision: The shop works asynchronously, the PDF follows later. It determines response time, error behavior and intermediate status.
ApplyingTransferred to a new situation
The shop should offer payment by bill and by card. Is “strategy patterns for payment types in the payment module” an architectural decision? And the renaming of a variable in it?
View the solution with justification
Yes, the strategy pattern: it shapes the contract between order and payment and any future payment method. The renaming no: It only works in one place; the team decides in the code.
EvaluateWeighing an alternative
The team also wants to keep the product search in SQL to run only one database. Weigh in.
View the solution with justification
This is due to less operational expenditure with a technology. In contrast, weaker full-text queries talk about descriptions and categories. The decision depends on how important search quality is as a quality goal.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Fundamentals & orientation: Architecture views.

7 Building blocks

Continue withArchitecture views