Component Model
A detailed view of the internal components within a system or service, showing their responsibilities, interfaces, dependencies, and how they collaborate to deliver functionality.
Purpose
The component model provides developers with a clear understanding of the system's internal structure, guiding implementation and ensuring consistent decomposition. It supports team organisation by clarifying ownership boundaries.
When to Use
Create during alpha when the internal structure of the solution is being designed. Refine during beta as implementation reveals the actual component boundaries. Use it to guide team structure and sprint planning.
How to Build
Start from the logical architecture and decompose each container or service into its constituent components. Each component should have a single, clear responsibility.
Define the interfaces each component exposes — what operations can other components call? What data does it accept and return?
Show dependencies between components — which components call which? Are dependencies synchronous or asynchronous? Minimise circular dependencies.
Document the technology implementation for each component: framework, language, key libraries. This guides developers on implementation approach.
Validate the component model against user stories — can each story be implemented by changing a small number of components? If not, the decomposition may need adjustment.
Tips
- Align components with Domain-Driven Design aggregates for a stable, business-aligned structure.
- Keep components loosely coupled — changes to one should not ripple across many others.
- Use the component model to inform team structure (Conway's Law).
- Show both provided and required interfaces for each component.
- Include data stores owned by each component to clarify data ownership.
Common Mistakes
- Creating too many fine-grained components that increase complexity without benefit.
- Not clearly defining component boundaries, leading to shared mutable state.
- Ignoring the relationship between component structure and team structure.
- Not showing data ownership, leading to shared databases and coupling.
- Creating a component model that does not match the actual code structure.
Government Context
In UK government, component models support the GDS principle of building small, composable services. They help demonstrate that the architecture supports independent deployment and team autonomy. For services that may be shared across departments, clear component boundaries enable selective reuse.