There Are No Natural Boundaries Waiting Inside Your Monolith

Finding the Natural Fault Lines in a Monolithic System

In the early days, a founder writing the first version of a product is making decisions that have to be right for that moment. The cheapest and fastest path is the only path that matters, and nobody is reviewing the architecture because there is no architecture to review. Code is the prototype, and the prototype is the product. When the product starts to serve real customers and the team grows, the code that produced the success is still there. Over time, multiple engineers with different backgrounds, different expertise, and different mental models modify it. Each one solved the problem in front of them, and none of them shared a plan, because the plan didn’t exist yet when the code first took shape.

1. Boundaries Are Made, Not Found

The first mistake in deciding where to split a system is believing that natural boundaries are waiting inside this code, ready to be discovered. They aren’t. In a system with no defined interfaces, the seam doesn’t exist. To find the boundary, engineers have to understand the product, the customer, and the problem the business solves, as well as how it’s going to evolve in the foreseeable future. Without that understanding, any cut is arbitrary. Product comprehension starts the process. The product has to answer three questions: what does it do, why do customers buy it, and what problems does it solve. When the answer is clear, the data model and the business capabilities behind the product become readable. From there, the architecture reveals its hidden structure. Until then, the codebase is a stack of historical decisions, and trying to find the cut in the code is reading the symptoms and missing the disease.

Conway’s Law, the observation that organizations design systems that mirror their communication structures, applies here. The way teams communicate shapes how the code arranges itself, and reorganizing one means reorganizing the other. This communication structure reflects the same reality in the present, or it will in the future. At its core, boundary identification is a product discipline, an organizational discipline, and a technical discipline, in that order.

2. Every Component Is a Product

A product has two points of interaction with the outside world, serving someone who demands it (which is ideally why it exists). The product itself may demand components or other products to function. Viewed from above, the relationship is fractal, the same pattern repeating at every scale. A product contains smaller products, and each component is a product that serves a demand and may demand something from other entities. The same logic that applies to a product applies to a company, which is a product with its own supply (what it offers the market) and its own demand (what it needs from employees, suppliers, and capital).

This view demands independence. A component has to expose what it offers and what it needs explicitly. Through interfaces and contracts, these relationships are defined, and when the contracts are clear, a team can work autonomously. With a stable contract, teams don’t need coordination meetings with other teams because the contract governs the interaction. Independence and efficiency are the two properties of a good boundary. Without them, the opposite takes hold: coordination meetings, instability, high incident rates, and global outages when one component fails.

The same principle applies to companies. A company offers a product, and the same logic of supply, demand, independence, and efficiency applies at every scale. The product defines what should be independent, and the code reveals where independence no longer holds.

3. Signals of Interdependent Boundaries

In a system with undefined interfaces, certain patterns expose where components join improperly. Most commonly, borrowed data from another domain exposes the problem. Consider a user’s full name stored in the orders table. When the name lives in the users domain, copying it into the orders domain is a shortcut that covers up the missing interface.

At the time, this shortcut wasn’t wrong. In a monolith (a single system where all the code lives in one place and shares one database), joining two tables in the database is faster than creating separate modules and retrieving the user’s name through a defined boundary. That engineer solved the problem in front of them using the cheapest and fastest path possible. The key insight: correctness evolves. What was right for a startup in experimentation mode becomes wrong for a growing business with distinct teams and scaling needs. That decision changes with the stage.

Clayton Christensen’s work on the decoupling point makes the same point with more rigor. Interdependence is correct when performance matters, and modularization becomes necessary when the basis of competition shifts to flexibility and speed. This decision is contextual, and the context is the stage of the business.

4. When the Margin Goes Negative

Every component, every product, and every company has to be profitable. The cost of keeping it alive has to be lower than the value it generates, and the difference is the margin. When the margin disappears or turns negative, the component is consuming more than it produces, and the situation demands a change. Several forms of change are possible. The team can reorganize the component, split it into two with more focused goals, or kill part of it to strengthen the surviving part. Satisfying demand more efficiently, but especially only working to satisfy real demand, is always the goal.

Consider a company that maintained two closely related operational units in a single component when it was young and small. Over time, the two operations grew in different directions, and working with both together created friction. Incompatible futures meant neither could evolve in ways that would be compatible with the other. Eventually, the company created two teams and split the component into two, and that was what the company needed at that specific moment.

The margin is the signal, and the response is structural. Reorganization, splitting, or partial killing are all on the table, and the right choice depends on what the component has to do and what it costs to keep doing it.

5. Boundaries Evolve With the Business

There is no such thing as a definitive cut. A boundary that is right this year may be wrong next year, and the organization has to keep assessing whether each component is still serving demand efficiently and whether the margin justifies its existence. Viewed through this lens, boundary identification is a continuous capital allocation discipline, and every cut or merge is a capital allocation choice driven by the economic reality of demand and the efficiency of serving it.

Cuts keep coming. What served as a monolith for the startup must give way to modules that serve the scale-up. A two-unit component has to split when its operations diverge. Eventually, teams replace the borrowed data with proper contracts when they can no longer tolerate the coordination cost. This work never stops, and the cuts don’t end.

6. Independence and Efficiency

A well-designed boundary has two defining properties: independence, meaning the component can evolve through a stable interface contract without coordination meetings with other teams, and efficiency, meaning the cost of keeping the component alive stays lower than the value it generates and it doesn’t slow down the rest of the system.

A bad boundary creates the opposite. Coordination overhead, instability, incidents that cascade across components, and negative margins are the symptoms of a cut that doesn’t respect the two properties. Making the right cut for the current stage of the business, knowing that future cuts will follow as the business changes, is the goal of boundary identification. Every architecture is temporary. The right architecture is the one that fits the business right now, and the discipline is to change it when the fit breaks.

7. Start With the Product

Starting with the product is the only reliable way to identify boundaries because once you understand the customer, the problem, and the value, you map the components that deliver that value and the boundaries become obvious. When a component’s purpose is clear, its boundary is clear; without a clear purpose, no amount of code analysis reveals the right cut.

This is why boundary identification is a product discipline with technical consequences. An engineer who tries to modularize without understanding the business will make arbitrary cuts. A founder who understands the customer but ignores the code will miss the technical signals. Both perspectives are necessary. The product defines what should be independent, and the code reveals where independence no longer holds.

8. Reading the Signals, Making the Cut

Software architecture is a living system that has to adapt as the business adapts. The right moment arrives when the fractal view of the product reveals a new product inside the existing one, with its own demand, its own margin, and its own team structure. It’s also when the coordination cost of the current architecture (the meetings, the cross-team handshakes, the integration work) is higher than the cost of splitting the component and locking the contract.

Boundary identification is the skill of reading the economic signals and making the cut at that moment. The cut comes too late when the margin has turned negative and the organization is drowning in the sync tax of cross-component work. Recognizing the moment and acting before that second case arrives is the real skill.

References

• Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28-31. The original paper establishing Conway’s Law: organizations design systems that mirror their communication structures.
• Christensen Institute. Modularity Theory. Explains the interdependence-modularity trade-off, the decoupling point, and when each architecture is appropriate based on market conditions.