How to Build Event-Driven Domain Architectures the Right Way
- Mark Kendall
- Oct 14
- 3 min read
How to Build Event-Driven Domain Architectures the Right Way
By Mark Kendall | learnteachmaster.org
🚀 Why Domain Thinking Still Wins
As modern systems scale, architects face an age-old question:
“How small should a microservice be?”
We’re told not to make them too big or too small, but that’s not very actionable.
The real answer lies in how we model our business domains, not how we slice our codebases.
When you pair Domain-Driven Design (DDD) with an Event-Driven Architecture (EDA), you get the sweet spot:
Services that are cohesive and meaningful
Systems that evolve independently
Teams that can move fast without breaking the core
🧩 A Real-World Example: The Drone Delivery Network
Let’s use a global drone-delivery company, AeroLink, as our example.
They manage fleets of drones that pick up, transport, and deliver packages across regions.
Their ecosystem includes:
Customer orders
Drone management
Package tracking
Delivery scheduling
Payment and billing
Each of these is its own domain.
But rather than dozens of microservices, AeroLink defines bounded contexts — one per major business capability.
🧭 Step 1: Design Bounded Contexts
Domain Context
Responsibility
Order Service
Handles customer orders and delivery requests
Fleet Service
Manages drone availability, health, and assignments
Package Service
Tracks package metadata, status, and routing
Delivery Service
Orchestrates pickup, flight, and drop-off
Billing Service
Calculates costs and issues invoices
Each context owns its own data and logic.
No shared databases. No direct dependencies.
⚙️ Step 2: Use Events as the Communication Fabric
Instead of letting services call each other directly, AeroLink uses Kafka as an event backbone.
Each service:
Publishes meaningful domain events
Subscribes to events it cares about
Reacts asynchronously, maintaining full autonomy
For example:
OrderCreated → triggers PackageService to prepare labels
DroneAssigned → triggers DeliveryService to schedule dispatch
DeliveryCompleted → triggers BillingService to generate invoices
🕸️ Step 3: Visualizing the Flow
flowchart LR
subgraph Domains["Domain Services"]
A[Order Service]
B[Package Service]
C[Delivery Service]
D[Fleet Service]
E[Billing Service]
end
subgraph Kafka["Event Backbone"]
K[(AeroLink.Events)]
end
A -->|OrderCreated| K
D -->|DroneAssigned| K
C -->|DeliveryCompleted| K
K --> B
K --> C
K --> D
K --> E
Key Idea:
Each service publishes what happened, not what to do.
Subscribers interpret events in their own domain language.
🧠 Step 4: Canonical Models — The Translator of Truth
AeroLink defines a canonical event model — a common JSON schema shared across all domains.
For example, every event includes:
{
"eventType": "DeliveryCompleted",
"domain": "Delivery",
"timestamp": "2025-10-14T16:00:00Z",
"payload": {
"deliveryId": "DLV-00942",
"droneId": "DR-134A",
"packageId": "PKG-338A",
"status": "Delivered"
}
}
That canonical shape lets any subscriber understand the message — even if it evolves later.
🧩 Step 5: Keep the Count Down, Not the Complexity
You don’t need a microservice for every noun.
You need one service per domain, and many subscribers that extend behavior.
Approach
Pros
Cons
Tiny microservices
High autonomy
Operational overhead, complex integration
Domain-driven services
Aligned with business, manageable count
Requires strong modeling discipline
Event-driven core
Decoupled, scalable
More asynchronous logic to manage
AeroLink runs just a dozen canonical domain services, each producing and consuming events — powering hundreds of adapters and integrations behind the scenes.
🔧 Step 6: Extending the Ecosystem
Adding new systems (like analytics, compliance, or customer notifications) is simple:
Just subscribe to existing events.
No schema changes, no code rewrites in core services — the system grows organically.
💬 The Big Takeaway
Domain boundaries define what your business is.
Events define how it communicates.
When you model your services around real business domains — and use events as the connective tissue —
you get a platform that scales with clarity instead of chaos.
✍️ Final Thought
Microservices aren’t about the number of containers.
They’re about clear ownership, consistent events, and business-driven design.
When you let domain language guide the architecture and events tell the story,
you end up with systems that are resilient, scalable, and elegant — no matter what industry you’re in.
Mark Kendall
Architect | Writer | learnteachmaster.org
Helping engineers turn chaos into architecture — one domain at a time.
Comments