Logical Architecture Diagram
A diagram showing the logical components of a system, their responsibilities, and how they interact, independent of physical deployment or specific technology implementations.
Purpose
The logical architecture separates concerns by showing what the system does (logically) without prescribing how it is deployed. This allows architects to reason about structure, responsibility allocation, and coupling independently of infrastructure decisions.
When to Use
Create during alpha when decomposing the solution into its constituent parts. The logical architecture informs both the physical deployment decisions and the team structure (Conway's Law).
How to Build
Identify the major functional areas or bounded contexts of your solution. Each should have a clear, single responsibility and well-defined boundaries.
For each logical component, document its responsibility (what it does), the data it owns, and the interfaces it exposes to other components.
Show the relationships between components: which components communicate, what data flows between them, and whether the coupling is synchronous or asynchronous.
Layer the architecture if appropriate — presentation, business logic, data access, integration. Show cross-cutting concerns (security, logging, monitoring) as aspects that span layers.
Validate the logical architecture against your non-functional requirements — does the decomposition support the required scalability, availability, and security characteristics?
Tips
- Align logical components with business capabilities for a stable architecture.
- Use Domain-Driven Design bounded contexts to identify natural component boundaries.
- Show data ownership clearly — each piece of data should have one authoritative source.
- Consider Conway's Law — your logical architecture will influence team structure.
- Keep it technology-agnostic at this level — technology choices come in the physical architecture.
Common Mistakes
- Conflating logical and physical architecture — mixing deployment concerns with logical structure.
- Creating too many fine-grained components that increase integration complexity.
- Not clearly defining component boundaries and responsibilities, leading to overlap.
- Ignoring data ownership, resulting in shared databases and tight coupling.
- Not validating the logical architecture against non-functional requirements.
Government Context
In UK government, logical architecture diagrams support the GDS principle of building for reuse. By separating logical concerns, components can potentially be shared across services or departments. The logical architecture should align with the government's domain model and reference architecture patterns published by CDDO.