Verticality structures a system into coherent domain aspects, making the domain the main driver for high level design.
Domain aspects are allowed to share technologies, frameworks and concepts – but are not bound to it. Verticality therefore facilitates local experiments in architecturally independent system parts.
Understand your context and domain
Even though domain aspects drive the high level architecture work, we need some overarching standardization on technological and conceptual aspects. Normally this ensures deployability, basic security or compatibility. Summarized under the term ‘macro-architecture’ we should aim for as little restriction as possible.
Structure your system into independent domains
Using domain concepts within our technical implementation helps with maintainability and long-term evolution. Mapping domain ideas into self-sufficient services (or verticals) is even more beneficial. This implies thinking about bounded contexts, data views and mapping mechanisms.
Care for deep technical decoupling
In order to use the bigger action scope for individual teams and to allow for domain-specific optimizations, domains should be technically decoupled. Down to platform or even container level. Working with asynchronous integration mechanisms, eventing platforms and isolated data views helps to make technical standardization an option, rather than a necessity.
Sector Rating Aspects
These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page.
|Important trends, technologies and topics are discussed and worked on in small and independent peer groups||Late majority|
|Business processes are actively managed and improved; their relation to software systems is taken into account||Late majority|
|System parts (services) are connected by well-defined interfaces||Early majority|
|Base frameworks and platforms are decided locally (e.g. decoupling through docker an other container technologies)||Early majority|
|Systems are defined by business domain boundaries (e.g. Domain Driven Design)||Early adopters|
|System parts (services) are isolated by business domain boundaries||Early adopters|
|Patterns like ‘dumb pipes, smart endpoints’ or ‘tolerant readers’ are used||Early adopters|
|Postel’s law is respected (Be conservative in what you do, be liberal in what you accept from others)||Early adopters|
|Systems are decoupled temporally (e.g. through asynchronous communication / event-driven systems)||Early adopters|
|The business domain is actively researched (e.g. Event Storming)||Innovators|
|Teams are optimized for flow (e.g. with Team Topologies)||Innovators|
|Technical decisions can be made on a per-team basis, without interfering with the overall organization||Innovators|
|Abstraction of infrastructure is achieved by serverless and functional programming (e.g. AWS Lambda)||Innovators|
|Peers support each other in their struggles (e.g. cooperative case advice)||Innovators|
- Feedback & Transparency: Create a common understanding about strategic and architectural decisions.
- Responsibility: Improve quality and problem awareness for individual verticals by installing a sense of responsibility.
- (Guided) Architectural Emergence: Increase overall efficiency of open micro-architectures by using proposal-based governance instead of hard rules.
- Technical Excellence: Enable vertical teams that are able to integrate their solution into the overall system.