Case Study - Service-to-Service Temptation
The temptation to shortcut directly from Cosmos → Planday, bypassing the Service Bus. This is what happens when you ignore DDD boundaries.
The Problem - Shortcutting directly from Cosmos → Planday
The temptation to bypass the Service Bus and call directly. It seems faster, but it creates coupling.
When you shortcut service-to-service calls, you:
- Create tight coupling between services
- Lose the ability to replay messages
- Make services dependent on each other's availability
- Break DDD boundaries
- Make testing and debugging harder
The Governance Gap - Ignoring DDD boundaries
Each service should own its bounded context. When you bypass the Service Bus, you break those boundaries.
Cosmos Connector should own fetching
It shouldn't know about Planday. It should just expose data.
Planday Connector should own transformation
It should consume data from the Service Bus and transform it for Planday.
The Service Bus is the handshake
It decouples services and enables replayability, resilience, and observability.
The Corrective Principle - Always publish to Service Bus; consumers subscribe
No service-to-service calls. Ever. Cosmos publishes. Planday subscribes. That's the contract.
Decoupling
Services don't need to know about each other. Cosmos doesn't need to know who uses its data.
Replayability
Messages can be replayed if needed, without affecting the source. This is crucial for debugging and recovery.
Resilience
When downstream is down, messages queue and process when available. No cascading failures.
Testability
Services can be tested in isolation. Messages can be mocked and replayed for testing.
The Outcome - Decoupled, testable, observable architecture
The corrective principle: Always publish to Service Bus; consumers subscribe. No service-to-service calls.
When you follow the Service Bus pattern, you get:
- Decoupled services — each service owns its domain
- Testable architecture — services can be tested in isolation
- Observable flows — messages can be traced end-to-end
- Resilient systems — failures don't cascade
- Replayable messages — debugging and recovery are easier
Cultural Outcome: Decoupled, testable, observable architecture.