Last time, we briefly explored various types of boundaries that should be considered when making architectural decisions for your application. Today, I want to share insights about the Problem and Solution Spaces.
This understanding will support you in defining more effective boundaries — both at the level of services and within the code itself.
Two Sides of the Same Coin
Having a concrete example is always useful. When we analyze the requirements of the Training Center — all the needs, issues, and stakeholder demands — they collectively form what we call the Problem Space. This space encompasses everything we aim to address and solve. It represents the rationale behind every future delivery.
In contrast, the Solution Space represents how we address these problems. It’s where our design and architectural decisions take shape, with all their benefits and trade-offs.
For example, if our stakeholders need to sell training offers (problem), we might support them by implementing a web service that allows potential participants to browse and book available trainings (solution).
But how is this connected to software delivery and architecture?
How Awareness of the Problem Space Improves Delivery
Understanding the problem space allows you to have meaningful discussions with domain experts and stakeholders. It fosters a productive feedback loop: they express their needs, and you explain the technical constraints and challenges.
Because you speak in domain terms, there's no need for translation — you can reason using a shared language. Likewise, when you encounter inconsistencies or misunderstandings in the system, you can approach the business for clarification. Again, a shared understanding and vocabulary make these conversations possible.
How the Solution Space Supports Architectural Decisions
When you're aware of the boundaries of your solutions and understand the specific problems they solve, you can translate that information into technical boundaries within your system. What will help you?
Group solutions that address related problems, use similar terminology, or require consultation with the same domain expert.
Cluster solutions used by the same users.
Align solutions with shared non-functional constraints.
Consolidate solutions that uses the same technologies.
And don’t worry — if you're eager to see how this plays out in practice, we’ll soon walk through concrete steps showing how this knowledge, combined with the outcomes of our Big Picture workshop, can guide architectural shaping.
One Problem, Many Solutions
Sometimes, you’ll hear a requirement and instinctively think you know the best way to implement it. But remember — most problems have multiple valid solutions. It’s crucial to consider various factors beyond your initial gut reaction before making a decision.
Returning to our example of selling training offers: one solution could be a web service; another might be a mobile app; and in some cases, direct sales without any software might suffice. Multiple approaches can solve the same problem, and what is even more intriguing, sometimes having all of them implemented is the most profitable path.
How the Problem Space Can Mislead You
To solve a problem effectively, you need the right amount of detail. Too little information might obscure the problem's complexity. Too much detail can overwhelm you with noise, distracting from what really matters. The better you understand your problem space, the better your judgment about these details will be.
Yet, your work doesn’t stop there. You must ensure these critical details are preserved in your code — next to the solution. Our memory fades, and over time we forget the reasoning behind past decisions. Embedding these details helps others (and future-you) understand the rationale behind the solution.
But again, balance is key—don’t omit too much, and don’t include irrelevant clutter.
Solution Boundaries Improve Problem Understanding
Everything discussed above is why defining clear boundaries around your solutions is critical. These boundaries might take the form of a dedicated service, a separate module, or even just a well-structured package or folder.
Imagine dumping all your solutions into one unstructured codebase — a monolith without any separation. What happens to those meaningful details? They become jumbled together. Even though specific subsets of details are relevant to particular problems, when everything is mixed, they create noise.
This noise makes it harder to understand what’s truly required to solve the task at hand. That’s one of the reasons navigating large, unstructured monoliths or bloated "microservices" becomes such a nightmare. Without proper boundaries, it's difficult to filter out irrelevant information.
Evolution Is Inevitable
Well-defined solution boundaries not only aid understanding but also support growth. Your problem space isn’t static — it evolves in response to market changes, new regulations, and stakeholder needs.
Sometimes, these changes affect past decisions. You might need to adapt your existing solutions. When that happens, don’t forget to also adjust the contextual details around those solutions.
Maybe there’s a new constraint? Perhaps something that once mattered is now obsolete? Or maybe some existing information has evolved? Whatever the case, these shifts need to be reflected in the system.
Conclusion
As you can see, Problem and Solution Spaces aren’t just abstract concepts. They are practical tools that improve your ability to deliver software with greater clarity, faster requirements analysis, and a smoother path to evolution.
No comments:
Post a Comment