Constraints
Constraints limit the solution space through binding specifications. They are documented as a given condition and checked for their origin.
- ConstraintMandatory requirement from outside.
- SpeciesTechnical, organizational, legal or convention.
- OriginThe origin shows who can change it.
Context
Why this is important
Anyone who considers their own choice to be a target excludes solutions without realizing it. Anyone who ignores a real requirement is planning past the contract. How you record decisions shows your own building block.
This building block explains fixed boundary conditions. For the prioritization of all formative influences, including the weighable ones, see architecture drivers.
At a glance · Constraints limit the solution space
Fixed or designable?
The shop carries technical constraints (payment provider, Java-runtime), organizational ones (small team without call will), legal ones (GDPR, PCI DSS) and a convention (API policy). Delivery and module cutting remain decisions of the team.
This is how you read the picture
- Constraint The lines with “fixed”, from payment providers to conventions.
- Species The column “Type” shows where the specification comes from.
- Origin The columns “Origin” and “Who can change it?” per row.
| Element | Species | Context | Origin | Who can change it? | Effect on the design |
|---|---|---|---|---|---|
| Payment provider | Technical technical | fixed fixed | Contract | Only on the Treaty | Adapter in the payment module, error handling designable |
| Runtime | Technical technical | fixed fixed | Existing Java-runtime in operation | the holding; | Choose frameworks and libraries at JVM |
| Team | Organisational | fixed fixed | Budget: small team, no separate call readiness | the management of the undertaking; | speaks for modular monoliths instead of many services |
| Customer data | Legal basis | fixed fixed | GDPR (EU Regulation) | legislators | Schedule erasure and accessibility |
| Card payment | Regulatory | fixed fixed | PCI DSS (industry standard, contractually binding) | The Card Organizations (PCI SSC) | store no card data, only provider’s payment identifier |
| Conventions | Convention | fixed fixed | Enterprise-wide API policy | Architectural guild or Business architecture | Contracts follow the house style |
| Delivery | Decision | Designable | Decision of the team | The team shall: | Choose or re-evaluate modular monoliths |
| Module blank | Decision | Designable | Decision of the team | The team shall: | Catalogue to Cut free invoice |
Benefits & limitations
Helps if:
- Binding framework conditions influence technology, operation or interfaces.
- A stated condition needs an owner and confirmation that it is binding.
Boundaries
- A preference can easily be presented as a requirement ('We have to do it this way'). Clarify its source and decision-making authority before treating it as a constraint; otherwise classify it as an Architectural Driver or record it as a Decision.
- Constraints become obsolete: contracts expire, platforms are replaced, laws change. Record a review date and re-evaluate affected decisions, for example in ADR.
In practice
- Record the wording and source. Note who set the condition and whether it is binding. This separates verifiable constraints from provisional preferences.
- Determine the scope and design impact. Identify affected components and excluded options. Distinguish the constraint from the other, negotiable goals among the Architectural Drivers.
- Assign evidence and review responsibilities. Define which role confirms compliance and when the constraint will be reviewed. Link the evidence to affected Quality Attributes.
Read the detailed explanation
Constraints can arise from laws, contracts, existing systems, responsibilities or available resources. Their source, scope and binding status determine their effect on the design. Architectural Drivers includes both these limits and prioritised goals; Quality Attributes describes desired properties of system behaviour.
A constraint can rule out options and raise further questions about storage, access or operations. Record its wording, owner, supporting evidence and review date. The team can then distinguish fixed conditions from preferences that remain negotiable.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Who can change the requirement for card payment, and who can change the delivery?
View the solution with justification
The requirement for card payment is only the card organizations via the PCI Security Standards Council; the delivery the team by decision.
ApplyingTransferred to a new situation
Marketing wants to store card data for one-click purchases in the shop. What opposes this, and who can change it?
View the solution with justification
PCI DSS, an industry standard of card organizations; only they can change it. Alternative: Only store the payment identifier (token) of the provider, the card data remains there.
EvaluateWeighing an alternative
Should the team treat the modular monolith like a constraint so that it is not constantly discussed?
View the solution with justification
This creates calm, but hides that it is a decision. Designable elections must be allowed to be re-evaluated in a changed context. Better: as a decision with reasons.
Explore further
These building blocks continue the thoughts of this page.
References
- arc42 · Chapter 2boundary conditions (opens in new tab)Explicitly specify technical and organizational requirements.
- GDPR (Regulation (EU)) 2016/679) for EUR-Lex (opens in new tab)Official text of the EU regulation on the protection of personal data.
- PCI Security Standards Council (opens in new tab)Publisher of the industry standard PCI DSS for card payments.