Architecture is multi-dimensional

architecting   architecture documentation   architecture  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.

Architecture means different things to different people. One reason it’s an overloaded term is because architecture is multi-dimensional. In this article, I briefly explore the different dimensions of architecture. But let’s first look at the classic definition of architecture.

The classic definition of architecture

My favorite definition of architecture comes from Len Bass and colleagues at the Software Engineering Institute, who played a key role in establishing software architecture as a discipline. They define software architecture as follows:

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

This is obviously an abstract definition. But its essence is that an application’s architecture is its decomposition into parts (the elements) and the relationships (the relations) between those parts.

As I describe in my book, the exact meaning of element and relationships depends on your perspective or view. Different stakeholders are interested in different dimensions. For example, a developer is typically concerned with elements, such as classes, packages, and modules, and the relationships between them, such as inheritance, associations and dependencies. In contrast, a network engineer typically focusses on elements, such as machines, and relationships, such as networks.

The classic 4+1 view model of architecture

The classic 4+1 view model of architecture describes software architecture using 5 views. The first four views are:

  • logical - the object model consisting of classes and their relationships
  • development - the application’s code compiled/packaged into modules (e.g. JAR files) and components (e.g. executable JARs or WAR files)
  • process - the application’s components as a set of running processes and the communication between them
  • physical/deployment - the physical/virtual machines and the processes that run on them

The fifth view (+1) are the scenarios that animate each of the four views and describe the architecture’s dynamic behavior.

Views != diagrams

It’s important to keep in mind that architecture views are not simply diagrams. While the primary way to document an architecture view is a diagram (e.g. using UML), the view itself is a set of elements and relationships. For example, the logical view is the object model, not a UML class diagram. The class diagram is merely one possible way to visualize the object model. Among other things, the view is also described using text.

The +1 is not an afterthought

It’s also to remember that the scenarios that document the dynamic behavior of the architecture are not an afterthought. They are an integral part of thee architecture description. Without the scenarios, you merely have a lifeless collection of boxes and lines.

My preferred architectural views

Over the years, my preferred way of describing architecture has evolved away from the classic 4+1 view model. For example, in my Using scenarios to reinvigorate your microservice architecture presentation, I described four dimensions: implementation, logical, deployment, and deployment pipeline.

These days I tend to think of architecture as having the following dimensions:

  • Domain (was logical) - the organization of programming language elements - classes, packages, etc - into subdomains/bounded contexts
  • Component (was implementation) - the organization of the subdomains/bounded contexts into executable/deployment units, e.g. monolith vs. microservices
  • Deployment - the deployment technologies, such as Kubernetes
  • Pipeline - how changes flow from developers to production

In addition, there are the scenarios that animate each of these views.

Domain-driven design (DDD) is focussed on the logical dimension. However, since it involves build-vs-buy decisions, it also touches on the other dimensions. For example, the purchased software that implements a supporting or generic subdomain could very well be a separate application, e.g. SaaS.

The success triangle is mostly focussed on the component architecture - monolithic architecture vs. microservice architecture - and the deployment pipeline architecture since these are the dimensions - along with a well-designed (e.g. loose (design-time) coupled) domain architecture - that affect the ability to deliver software rapidly, frequently, reliably and sustainably.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help

architecting   architecture documentation   architecture  

Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon MJXJDTBJ to sign up for $95 (valid until May 22nd, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,

The Eventuate platform

Use the platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

Join the microservices google group