Tools & methods
Choose your task. Compare what the tools produce, then start where you can make progress.
Which capabilities and qualities does the shop need?
Clarify what the shop must deliver and how well it should do so.
Requirements
Observable, testable capability
In the shopA customer places their cart as an order, and the shop assigns the order ID B-1042.
Requirements
Prioritised, testable quality goals
In the shopIllustrative: 95% of payment responses arrive within 800 ms at 20 requests per second.
Where do terms and rules apply?
Shape business responsibilities and integration relationships to fit.
Domain
Clear domain models with named boundaries
In the shopOrder and invoice both use “amount” and “status”, but mean different things and therefore get separate models.
Domain
Understandable dependencies between domain models
In the shopInventory, payment and order align within the team; the payment provider sets its own model, and the shop translates.
Method in building block Domain-Driven Design
Shared process view with open questions
In the shopThe team arranges “order placed”, “payment authorised” and “inventory reserved” and clarifies when an order counts as confirmed.
Which option fits best, and why?
Compare design options and record the decision.
Evolution
Reasoned choice with visible consequences
In the shopModular monolith or separate services: the team weighs change autonomy against operational and network effort.
Documentation
Traceable decision with consequences
In the shopThe ADR records that the shop remains a modular monolith and names the operational consequences.
What do the building blocks, flows and operation look like?
Make the shop's structure, flow and operation visible, and document them.
Documentation
Aligned views of boundaries and components
In the shopShow customers, payment provider and shop as context, with web application, modular monolith and database as containers.
Documentation
Traceable workflow including critical alternatives
In the shopOrder, payment and provider clarify P-731; if a response is lost, the shop queries the payment status.
Documentation
Visible runtime dependencies
In the shopThe shop application runs on two instances with a managed database; the payment provider remains external.
Documentation
Consistent architecture documentation for the team
In the shopThe shop documentation links the order-confirmation target with the payment flow, the ADR on module structure and the open restore risk.
Does the architecture hold up, and where are the open risks?
Validate architecture assumptions early and repeatedly.
Evolution
Concrete findings and agreed actions
In the shopThe team tracks order completion when a payment response is delayed, and reviews the status model, resumption and operational indicators.
Evolution
Early feedback on architecture rules
In the shopAn automated test flags unauthorised database access between the order, shipping and invoice modules outside the module contracts.
Security
Prioritised threats with countermeasures
In the shopOn an incoming shipping notification, the team asks whether a compromised partner could change the status of other orders.
Documentation
Prioritised risks with concrete next steps
In the shopThe restore with payment reconciliation has not yet been tested; the log names the owners and the evidence.
How does the team detect and contain critical failures?
Plan reliability and recovery for the shop.
Operations
Measurable reliability goal with an action rule
In the shopOrder confirmations should be visible within two seconds, illustratively at 99.0% or 99.5% over 30 days, with a response rule.
Operations
Evidenced recovery path with measurements
In the shopAfter damage to the order index, the team restores in isolation and reconciles the orders with the payment system.