Relationships
Declare static architecture interactions, direction, technology, and data flow
Relationships describe the dependencies the architecture intends to exist. Open Model → Relationships.
Describe Intent
A useful Relationship answers:
| Question | Example |
|---|---|
| Who initiates and who receives? | Checkout API → Orders Service |
| What crosses the boundary? | Submit order command |
| How does it travel? | Synchronous HTTPS API |
| What mediates it? | Broker or integration platform, when applicable |
| What evidence supports it? | Contract, source path, ADR, or operational note |
Capture synchronous versus asynchronous interaction, direction, technology, endpoint or broker context, and a description meaningful to reviewers.
Broker-mediated delivery is still one logical producer-to-consumer Relationship; the broker is routing context unless the architecture intentionally models separate dependencies.
Create And Review
Create Relationships from the catalog, Sketch, or a View editor. Every creation changes the canonical model even when initiated from a canvas.
Relationship detail connects static intent to documentation, workflow transitions, endpoint Data Model context, analysis, and published evidence.
Analysis Impact
- Complexity uses structural dependency patterns.
- Blast Radius follows dependency and workflow impact paths.
- Coupling compares Relationships with workflow co-activity.
- Context Map adds strategic DDD meaning at a broader boundary level.
An edge on a View should never be the only explanation of a dependency.