In software architecture, we often talk about boundaries — and for good reason. Boundaries provide valuable insight into various aspects of our systems: cohesion, dependencies, complexity, and more.
Today, I want to walk you through several types of boundaries that should be considered when designing software architecture. Broadly speaking, they fall into two categories:
Knowledge-specific: These are shaped by business knowledge, requirements, and policies.
Technical: These are defined by technical constraints and non-functional requirements.
Domain Boundaries
A domain can be understood as an area characterized by consistent language and terminology. These boundaries are driven by business knowledge.
Consider our example: a Training Center. The system should facilitate structured training and education across various professional fields. We can easily identify a few distinct, unrelated domains:
Teaching
Marketing
Accounting
Sales
...
Each of these domains demands a unique set of skills, specialized knowledge, and its own language.
Solution Boundaries
Another important architectural perspective involves the boundaries of your solutions. What does that mean?
Domains are full of problems that need solving, such as verifying trainers' qualifications, promoting new courses, or signing agreements. These problems can be categorized into three groups:
Problems not supported by the system – e.g. marketing and accounting might be handled entirely outside the system.
Partially supported problems – e.g. assessing trainers' skills might involve both manual and automated steps.
Fully supported problems – e.g. training recommendations could be fully automated based on existing data.
Sometimes solution boundaries align with domain boundaries, but often they don’t. A solution may span multiple domains or be limited to a subset of one. Depending on the context, it might be helpful to explicitly visualize these boundaries to improve understanding of value, process consistency, or policy enforcement.
Component Boundaries
Component boundaries relate to deployment units — components that can be independently stopped, modified, and restarted. Though they may require contracts and APIs management and release coordination, they are deployed on specific hosts with allocated resources like CPU and RAM.
Database Boundaries
Database boundaries are another crucial consideration. Even with clearly defined component boundaries, your database structure may not reflect them. You can implement database boundaries in several ways:
Shared schema and shared tables (no isolation)
Shared schema with dedicated tables per component
Separate schemas on the same host
Separate databases on different hosts
Each approach comes with its own trade-offs. There is no one-size-fits-all solution.
Infrastructure Boundaries
Having component boundaries is one thing — but where and how they run also matters. You might end up running all components on the same host or choose complete isolation.
There are many options here, from running everything on a single host to distributing services across multiple hosts. You might also decide that you don't care about this level of separation. Containers and VMs further complicate this area, introducing new boundaries to consider.
Challenges with Boundaries
As you've seen, designing architecture is not about selecting a single perspective and making decisions in a vacuum. Here are some common challenges:
Architecture is a combination of boundary choices – Your decisions will depend on factors such as cost, scalability, and business requirements. In some areas, domain boundaries may be the focus; in others, infrastructure separation may take precedence. Most systems combine all of these.
Boundaries often differ across perspectives – Some engineers believe that all boundaries should align perfectly. While that occasionally happens, it's rare. Each perspective serves a different purpose and reflects different concerns.
Boundaries evolve, and your system should too – Knowledge-specific boundaries (like domains and solutions) change over time as your understanding grows. Unfortunately, many teams fail to reflect these changes in other areas such as component, database, or infrastructure boundaries. But adapting your system to new knowledge improves maintainability and builds confidence in evolving your architecture.
Conclusion
Software architecture is inherently complex. As systems grow larger and business needs more intricate, the challenge intensifies — but so does the reward.
Don’t get fixated on a single approach. Analyze your requirements and constraints, weigh the trade-offs, and choose the most appropriate solution. And never be afraid to change your mind when reality proves a decision wrong. That adaptability is key to long-term success and healthy system evolution.
No comments:
Post a Comment