Architecture should model responsibilities before modeling systems
Most architecture diagrams show systems. Boxes labeled with technology — the booking service, the payments database, the notification queue. These diagrams describe what exists. They do not describe why it exists or what it is responsible for.
Relative Architecture starts differently. Before a system is named, a responsibility is named. What is this part of the business committed to? What does it own? What does it not own? Domains group responsibilities that share vocabulary and authority. The diagram that emerges reflects the business structure, not the technology structure.
When the business changes — and it will — a responsibility-first architecture changes cleanly. You find the responsibility that changed, update its boundary, and the implications are visible. In a system-first architecture, the same change ripples unpredictably through layers of technical coupling that nobody fully mapped.
Draw the responsibilities first. The systems follow.