Keep it together or split it? Making boundary decisions under uncertainty

You’ve explored the problem space, defined domain boundaries, and now you face a critical decision: how to shape the solution boundaries.

Sometimes, it’s not obvious whether a set of responsibilities should stay together or be separated. And that’s perfectly normal. Architecture does not operate in conditions of complete certainty - it exists precisely where decisions must be made despite ambiguity and incomplete information.

In such situations, there are several viable approaches:

• learn more until confidence in one option increases
• merge responsibilities into a single solution
• keep them separated

Before going further, it’s worth clarifying: this is not a situation where we don’t know what or how to build (as described in here). The challenge here is different - we have enough information to proceed, but not enough to define boundaries with confidence.

Example: One domain, two sales models

Let’s consider a simple case. Our domain is a Training Center, and the task is to decide whether the sales process for dedicated and open trainings should live within the same module/component/service:

• Dedicated training – tailored to a specific company, scheduled on demand, customized in scope, content, and timing
• Open training – listed in a catalog, scheduled on fixed dates, open for individual registration

There are clear differences, but also significant overlap between these processes. At this stage, no option clearly dominates. This leaves us with three choices: explore further, keep it together, or keep it separated.

Let’s examine each of them.

Option 1: Delay the decision and learn more

You can postpone the decision and continue exploring the problem space, aiming to make a more informed choice once additional insights emerge.

The challenge? This is not always feasible—especially when the decision blocks further progress and pressure is building to move forward.

Pros:

• the decision is based on richer input

Cons:

• delays progress
• difficult to determine when to stop
• additional knowledge may still not eliminate uncertainty

When to use?
When postponing the decision is safe and does not block delivery. If you find yourself in such a situation, it’s also a good moment to evaluate whether other architectural decisions could make delaying easier - or even possible.

Applied to the case:
Since this decision affects a critical part of the system, there will likely be strong pressure to proceed. That makes this option harder to apply.

Option 2: Keep everything in one boundary

Another option is to place uncertain responsibilities within a single boundary and treat them as one solution.

Pros:

• lower infrastructure complexity
• fewer components to maintain
• shared knowledge remains centralized

Cons:

• if the decision proves wrong, splitting the component can be difficult
• risk of accumulating unrelated concerns

When to use?
This approach works well for supporting or generic subdomains, because:

• business logic is relatively simple
• correcting the decision later is easier
• even if decision not corrected, the impact is limited

Applied to the case:
Here we are dealing with core domains, so applying this approach introduces significant risk.

Option 3: Separate from the start

Finally, you can separate the solutions from the beginning.

Pros:

• clear separation of concerns
• smaller contexts improve understanding and changeability
• merging later is easier than splitting

Cons:

• handling shared functionality becomes a design challenge (duplication vs extraction)
• increased infrastructure complexity
• more components to manage

When to use?
This is a strong choice for:

• core domains, where clarity and flexibility are critical
• teams experienced with distributed systems
• environments that support continuous change and evolution

Applied to the case:
This scenario strongly favors separation. Both dedicated and open training sales are core to the business. Keeping them separate enables faster adaptation to evolving needs.

If future insights reveal overlap, merging selected parts will be far easier than untangling a tightly coupled solution.

Architecture is evolution, not certainty

Lack of certainty is not a valid reason to block architectural decisions.

Moving forward in uncertainty is part of the job. Once you accept that evolution is inherent to architecture, it stops being a source of discomfort - and becomes just another problem to solve and another decision to make.