Rules spread across the system
Important behaviour is repeated in interfaces, integrations, scripts, or manual processes, making outcomes difficult to predict and change safely.
02 · Technology layer
Application Layer
Shape maintainable application logic, services, and boundaries around the product's real workflows and responsibilities.
The context
Why this layer deserves deliberate decisions.
The application layer turns product behaviour into dependable rules and services. Clear boundaries make it easier to understand where decisions belong, how data changes, and how the product can evolve without every change affecting the whole system.
Responsibilities overlap
Modules or services know too much about one another, so a small change produces broad regression risk or requires coordination across unrelated areas.
Technical shape leads the product
Framework or service choices have been made before workflows, ownership, data, and operating needs are sufficiently understood.
Areas of attention
Connect product needs to technical responsibilities.
The appropriate depth depends on the current system, the decision in front of the team, and the consequence of getting it wrong.
01
Domain and workflow modelling
Represent the important concepts, decisions, state changes, and exceptions in language the wider team can understand.
02
Application boundaries
Separate responsibilities where doing so improves clarity, ownership, testing, deployment, or future change.
03
Service and API behaviour
Define inputs, outputs, errors, permissions, and compatibility expectations at useful system boundaries.
04
Maintainability and verification
Choose structure and automated checks around the behaviour where defects or change would have meaningful impact.
Potential artefacts
Make the technical direction usable by the team.
The exact artefacts follow the question and available evidence. Their purpose is to support implementation, review, and future ownership.
- 01Application context and responsibility map
- 02Key workflow and state models
- 03API or service behaviour definitions
- 04Architecture decisions with trade-offs
- 05Implementation stages and verification approach
Decision framing
Use context and evidence before adding complexity.
A useful direction explains the inputs, how it can be evaluated, and where its boundaries remain.
What we need to understand
- Critical business rules and workflow variations
- Existing applications, services, dependencies, and ownership
- Data sensitivity, access, and audit needs
- Expected usage, change patterns, and operational constraints
Evidence of a useful direction
- Responsibilities are understandable to product and engineering stakeholders
- Important state changes and failure paths are explicit
- Interfaces between components have defined behaviour
- The proposed structure can be owned by the intended team
Important boundary
A more distributed architecture is not automatically more maintainable. Service separation, new platforms, or major rewrites should be justified by concrete ownership, release, reliability, or scaling needs.
Working path
Move from current reality to an owned direction.
These stages are adapted to the size of the decision. Each should leave the next choice clearer than it was before.
Map the behaviour
Understand users, workflows, rules, data, dependencies, and exceptions before choosing system boundaries.
Evaluate the current shape
Identify useful assets, coupling, risks, and constraints that influence whether to retain, refactor, integrate, or replace.
Define responsibilities
Document application boundaries, contracts, decisions, and quality needs at a proportionate level.
Deliver in stages
Sequence implementation and migration so behaviour can be verified and operational risk remains visible.
Technology questions
Useful details to clarify.
Does every application need separate services?+
No. A well-structured single application may be the clearest option. Separation is useful when specific responsibilities, ownership, reliability, or deployment needs justify it.
Can you work with an existing backend?+
Yes. We can review the current structure and identify whether focused changes, new capabilities, integration, or a staged modernisation path best fits the objective.
How are framework choices made?+
Choices should follow product behaviour, team capability, existing context, operating needs, security, and the expected cost of change rather than popularity alone.
What should an architecture decision include?+
A useful record explains the context, options, criteria, trade-offs, chosen direction, known limitations, and circumstances that may require the decision to be revisited.
Start a conversation
Need clarity around the application layer?
Share the product, current system, constraints, and decision in front of your team. We can help frame a practical next step.