Stop Building Distributed Monoliths: How to Find Real Business Boundaries

How to avoid technical coupling and design independent software that match your organization.

I’ve seen teams spend (waste?) time in multiple meetings debating Kafka, Kubernetes, REST, GraphQL, PostgreSQL, DynamoDB, and every other technology under the sun.

And then fail because they didn’t understand the business they were building.

In today’s issue, I want to share why understanding the domain is one of the most important skills in software architecture, especially when building distributed systems, and even in the era of AI code generation.

Most architectural problems don’t start with technology but with a misunderstanding of the business.

Have you ever felt like everyone on your team speaks a different language when designing a system?

In today’s issue, I want to share a small conceptual correction that will save us major headaches when designing distributed systems, because we often mix apples and oranges when talking about architecture.

What a Domain is NOT

When a team starts building software, it’s common to find purely technical divisions like a user service, a database service, or an email service.

But the domain has nothing to do with Java, Python, PostgreSQL, or Kafka. All of those are simply technological decisions.

☝🏼 The domain exists even if there is no software; if we turned off all of an airline’s servers tomorrow, the concepts of ‘Booking’, ‘Flight’, and ‘Overbooking’ would still exist in their business.

So, What Exactly Is a Domain?

According to Eric Evans in Domain-Driven Design (DDD)

The domain is the sphere of knowledge or activity—specifically, the problem area that the user is trying to solve with the program.

👉🏼 The domain is the problem we are trying to model, not the technical solution or the database.

A large domain (like E-commerce) is divided into specialized areas with their own rules, which DDD calls Subdomains:

• Catalog and Inventory

• Ordering and Billing

• Logistics and Customer Service

Bounded Context: The Boundary of Your Model

If you ask around your company what a “Customer” is, for billing, it will be a legal entity that pays, and for support, it will be a user opening tickets. Both are right.

Por eso necesitamos un Bounded Context, que es el límite explícito dentro del cual un modelo de negocio tiene un significado preciso y consistente.

Mixing these boundaries without clear borders is the reason why software in large systems becomes fragile, error-prone, and extremely difficult to understand.

At this point, you may ask:

Why this matters in Distributed Systems?

In distributed projects, you don’t just divide code; you also divide responsibility, data, and communication between autonomous teams (Conway’s Law).

The classic mistake is creating services based on database tables (`UserService`, `ProductService`), which leads to cascading calls and a distributed monolith.

👉🏼 DDD proposes looking for business boundaries instead of arbitrary technical frontiers; therefore, a microservice should naturally map to a Bounded Context.

Protecting the Domain: Hexagonal, Clean, and SOLID

Once you identify your business boundaries, you need tools to protect that core from external contamination:

• Hexagonal and Clean Architecture: They ensure that the core business rules remain independent of the UI, frameworks, and databases using adapters. The domain doesn’t know what REST or AWS is.

• SOLID Principles: They don’t define the domain, but they provide discipline at the module and class level so that the business logic doesn’t get contaminated with technical details of SQL or protocols.

You have explanations about what a Domain is. Let's wrap up for today.

✨ Takeaways

Keep this in mind:

• The domain is the business: The software structure must reflect the business problem, not the chosen technology.

• Poorly defined boundaries = Chaos: The main consequence of not understanding the domain is drawing the wrong borders, causing coupling and architectural debt.

• Isolation tools: DDD is used to model complex domains; Clean, Hexagonal, and SOLID are the shields that prevent technology from muddying that model.

If I had to summarize everything in a single sentence, it would be this:

The structure of your software should reflect the structure of your business, not the structure of your technology.

Understand the domain first. The technology decisions become much easier afterward.

Write it in the comments, I read and reply to all!