Getting Started
The challenge
Managing complex distributed systems requires a coordinated, multi-disciplinary approach. Business leaders, architects, developers, and infrastructure teams each bring unique expertise — and each needs to understand the others' perspective to build systems that evolve as the business evolves.
Built on established foundations
Relative Architecture does not reinvent the wheel. It connects established disciplines into a unified model that all four roles can work from:
Domain-Driven Design — the vocabulary for boundaries, ownership, and domain language is DDD. If you know DDD you will recognise the capability as a bounded context realised as software, and the domain vocabulary as something the capability owns, never borrows.
CQRS — the separation of commands and queries maps directly to the capability model. Commands cross the boundary in. Projections serve queries from a local read model built from events. The separation is structural, not optional.
Design by contract — the event contract and the capability contract are the formal expression of every boundary in the system. The contract is written before the code. The implementation honours it.
Event-driven and reactive design — the three messaging patterns, choreography, and the cascade diagrams are all expressions of event-driven and reactive principles applied to the capability model.
Each discipline contributes something the others do not. Relative Architecture is the synthesis — the connective tissue that makes them work together as a single coherent model.
Self-similarity — the same model at every level
One principle runs through everything in this publication: the same architectural model applies at every level of decomposition. A module inside a capability follows the same pattern as a capability inside a domain, which follows the same pattern as a domain inside a platform.
This matters practically because it means you can start anywhere. A developer working at the capability level and a business architect working at the platform level are applying the same thinking at different scales. The vocabulary is the same. The boundary rules are the same. The interaction patterns are the same. Reading outside your role is not just encouraged — it is how the model reveals its full depth.
The lab series works within a single hotel domain. It demonstrates capability-level patterns in depth. Domain aggregation, platform rollups, and enterprise hierarchy follow the same model — but that is a later conversation.
How to get started
Each article provides insight into one or more perspectives — business, architecture, development, and infrastructure. Based on your role here is a suggested path. Do not be afraid to read outside your role — the most valuable insights often come from understanding how others look at the same problems you face.
Everyone
- The Relative Architecture Manifesto — short and to the point, this provides the foundation for everything moving forward
- Start Here — an expansion of the manifesto that provides more detail without overwhelming you
Business Leaders
- Value Propositions — quite simply, the why behind all of this
- Roles & Responsibilities — how teams organise around these concepts. There may be more business involvement than what is currently expected in your environment today
Architecture
applies to business, product, enterprise, software and more
- Core Concepts — the design vocabulary. A particular aspect or idea discussed in detail, still suitable to be read in a single sitting
- Roles & Responsibilities — relationships, boundaries, and the artifacts teams use to communicate
Development
- Core Concepts — the implementation contracts. The precise vocabulary that connects business intent to working code
- Roles & Responsibilities — relationships, boundaries, and the artifacts teams use to communicate
Infrastructure
- Core Concepts — the operational constraints. What the architecture requires from the infrastructure beneath it
- Roles & Responsibilities — relationships, boundaries, and the artifacts teams use to communicate
- Infrastructure — brokers, gateways, and the servers, databases, and cloud or on-premise components that directly support the platform. Focused on infrastructure that directly supports platform architecture, not general ops
The articles are designed to stand alone but reward reading in sequence. Start where your role suggests, read outside it when curiosity pulls you, and subscribe when you want to stay current. There is more on the way.