Domain-Driven Services - Just the Right Size

Microservices were too small, SOA was too big. DDS is juuuuust right.

I never really bought into the MS hype. It has always looked like adding too much complexity related to benefits. Don't get me wrong, breaking large blocks of deployed code into small, independent services makes a lot of sense—in very select cases (like strangler fig) or in simple business models with massive scale (netfilx). But in general they were too small for complex domain level coupling seen in complex business concepts. As more complicated systems scaled, what should’ve been a dream architecture became a nightmare of tangled dependencies, slow performance, and operational headaches.

I’ve been involved with a lot of microservices programs with software architects, and let me tell you, there’s a lot they don’t warn you about in those sleek conference talks. What starts as a neat collection of independent services quickly becomes an unmanageable mesh of APIs, database inconsistencies, and teams struggling to sync changes without breaking everything. And then there’s the distributed monolith—where your microservices are technically separate but so interdependent they might as well be glued together.

That’s why I started rethinking the approach. Instead of structuring services around arbitrary technical functions (users, orders, payments), why not build them around business domains that actually make sense? That’s how I arrived at Domain-Driven Services (DDS)—an approach that takes the best parts of Domain-Driven Design (DDD) and applies them at the service level.

Building Better Integration Architecture

This work and work like it is being done in the Integration Architectures group led by @Brice Ominski and more. This group (which will soon have its own community and forum) is coallating and bringing together best of breed working integration architecture techniques. If you would like to learn this and more join our community in Mighty Network (Integration Architecture) and signup for the latest Integration Architecture CITA-A course: https://www.iasaglobal.org/integration-architecture/.

What’s Wrong with Microservices, Really?

Before I discuss Domain-Driven Services, let’s look at the problems with microservices:

1. Service-to-Service Chatter Gets Out of Control

Splitting everything into separate services sounds nice until you realize every action requires multiple network calls. Want to show an order summary? That’s a request to the order service, then a request to the user service, then inventory, then shipping… and so on. The latency adds up fast. But even worse is the interdependence. And when this is a transactional change happening over a period of time you end up with event hell.

2. Data Is a Mess

Each service owning its own database sounds great—until you need consistent data across services. Distributed transactions? Eventual consistency? Hope you like debugging weird race conditions at 2 AM.

3. Too Much Overhead

Managing 50+ services means maintaining 50+ deployments, 50+ monitoring setups, and 50+ failures to diagnose. Oh, and now your ops team hates you.

4. The Boundaries Are All Wrong

Microservices tend to get split based on technical concerns (e.g., “this handles users,” “this handles orders”), but that’s not how real-world businesses work. The result? Services that don’t actually reflect the domain and just make life harder.

What Are Domain-Driven Services (DDS)?

So, here’s my alternative: Domain-Driven Services. Instead of breaking things up by technical function, you structure services around real business domains—areas that naturally exist in the business.

Principles of DDS:

1. Bounded Contexts Define Service Boundaries – A service isn’t just a collection of APIs; it represents a true business function with clear ownership of its data and logic. Try using the BC Canvas - https://iasa-global.github.io/btabok/bounded_context_canvas.html
2. Ubiquitous Language – Developers, architects, and business people should all use the same terms to describe things. No more miscommunication between the code and the business.
3. Aggregates and Entities Stay Local – A service owns its data and logic. No more unnecessary cross-service calls just to validate some rule.
4. Domain Events Drive Communication – Services don’t constantly ask each other for data. Instead, they publish and listen for events when something important happens.

DDS in Action

Let’s take an example. Imagine an e-commerce system with traditional microservices:

• User Service (handles users)
• Order Service (handles orders)
• Discounting Service (handles discounts)
• Cart Service (handles carts)
• Payment Service (handles payments)
• Inventory Service (tracks stock)
• Shipping Service (handles deliveries)

At first glance, it looks fine. But in reality, every order involves multiple service calls: checking inventory, reserving stock, charging payments, and scheduling shipments. It’s brittle, slow, and hard to maintain.

How DDS Would Restructure It

Instead of organizing by function, we organize by business domains:

• Ordering Domain (handles order placement, validation, and confirmation)
• Fulfillment Domain (manages stock, warehouse processing, and shipping)
• Payments Domain (controls transactions, refunds, and billing)

Each domain fully owns its data and business logic. Instead of constantly calling each other, they communicate through domain events (when necessary) and straightforward APIs in most cases:

• When an order is placed → an OrderPlaced event is published.
• The Fulfillment Service listens and adjusts inventory.
• The Payment Service listens and processes the charge.
• The Shipping Service listens and schedules delivery.

No constant polling. No unnecessary API calls. Just autonomous services reacting to business events.

Why This Works Better

• Less Chatter – Since services own their logic, they don’t need to ask others for permission.
• More Resilience – If one service goes down, it doesn’t take the whole system with it.
• Better Business Alignment – Teams can build services that actually map to the business structure.

Making the Switch from Microservices to DDS

If you’re thinking, Great, but how do I transition?, here’s what I’d recommend:

1. Identify Real Business Domains – Work with stakeholders to map out what your system actually does, not what your database tables say.
2. Group Services by Domain, Not Function – Instead of splitting by “Users” and “Orders,” think about broader responsibilities like Ordering and Fulfillment.
3. Move Towards Event-Driven Communication – Replace synchronous API calls with event-based updates where it makes sense.
4. Refactor Gradually – You don’t need to rebuild everything overnight. Start by refactoring one domain at a time.

I’m not saying Domain-Driven Services are a silver bullet. No architecture is perfect. But after wrestling with microservices for years, I can say with confidence that aligning services with real business domains makes everything easier—from development to maintenance to scaling.

If you’re dealing with microservices chaos, maybe it’s time to rethink the approach. DDS might just be the way forward.

References

• Building Domain Driven Microservices – Medium
• Microsoft: Designing a DDD-Oriented Microservice