Defining Component Responsibilities
Learn how to document what each component in your system does and does not do using component responsibility blocks.
Clear component boundaries prevent the "who owns this?" question during incidents and feature development. Component responsibility blocks capture what each service or module does, what it explicitly does not do, and how it interacts with other parts of the system.
Why Document Responsibilities
Without clear boundaries, teams encounter friction:
Adding a Component Responsibility Block
Component Responsibility Fields
Good Responsibilities
| Type | Examples |
|---|---|
| Specific actions | Process credit card payments via Stripe |
| Data ownership | Maintain the authoritative record of customer addresses |
| Event emission | Generate and send order confirmation emails |
Good Out of Scope Items
| This Component | Handled By |
|---|---|
| User authentication | Identity Service |
| Invoice generation | Billing Service |
| Notification delivery | Notification Service |
This example uses the NeoArc Component Responsibility content block.
When to Create Component Responsibility Blocks
Create these blocks when:
Keeping Responsibilities Current
Review component responsibility blocks when:
This example uses the NeoArc Component Responsibility content block.
Connecting to Diagrams
Component responsibility blocks work well alongside architecture diagrams. The diagram shows structure and connections. The responsibility block captures the narrative: what each box in the diagram actually does.
The component responsibility blocks you see in this documentation demonstrate the same format you will use to document your own services.