Finding that special plus one for your architecture

I spend a lot time talking with clients about their software architecture. Either I’m reviewing their microservice architecture or helping them migrate from a monolithic architecture to a microservice architecture. Most engagements start with the client presenting their AS-IS architecture. This article describes some common problems with how architecture is documented and/or presented and how it can be improved.

Clearly define the meaning of the boxes and lines

Quite often the architecture is presented as a series of diagrams that look something like this.

(Names changed to protect confidentiality 😀)

On the one hand, a diagram consisting of boxes and lines is a good start. After all, a classic definition of software architecture by Len Bass and colleagues at the Software Engineering Institute is:

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.

In other words, the architecture can be described visually as a set of boxes and lines.

However, a common problem with such diagrams quite often the meaning of those boxes and lines is often unclear or ambiguous. For examples, let’s assume - since that’s not clear - that the elements in this diagram are services. Does the arrow from Order Management to Consumer Management represent an API dependency? Perhaps, it does? Or, does it represent Order Management directly accessing Consumer Management’s database. Since direct database access is a major architectural smell, it’s essential that a diagram clearly describe the nature of dependencies.

Here are two ways to improve such a diagram First, include a legend that describes the diagram’s visual notation. Second, briefly describe of each of the elements and relations that are shown in the diagram

Architecture is multi-dimensional

Another common problem is that the architecture documentation might only describe one aspect of an architecture, such as the services. In reality, however, architecture is multi-dimensional. A classic format for describing software architecture is the 4+1 view model, which I described in my Code Freeze 2018 presentation and in my Microservices Patterns book.

An architecture is described by a set of, what was originally, four views - the precise number does not matter. Each view consists of certain types of elements and relations and shows an aspect of the architecture from a particular stakeholder’s perspective. The architecture documentation for a modern enterprise application should probably consist of views that describe key classes and their relationships; services and their dependencies; infrastructure elements; etc.

Bring your architecture to life with collaboration/sequence diagrams

Another common problem with architecture documentation is that it often only shows the static structure of the architecture. The views, which describe the architecture’s elements and relations, are only one part of the architecture description. The other key part is the +1, which are the scenarios that show how the elements within the view collaborate. These scenarios bring your architecture to life. They connect it back to the application’s functional requirements - the user stories or scenarios. It’s vital that you include them in any description of your architecture.

You should document each architecturally significant scenario and show how the elements of your architecture collaborate. A UML sequence diagram is are a very convenient way to to visualize how elements collaborate.

Also, it’s often useful to briefly describe each step in the flow. For example:

  1. The Client makes Create Order request to the API Gateway
  2. API Gateway proxies the request to Order Service
  3. The Order Service invokes the Restaurant Service to validate and price the Order
  4. The Order Service invokes the Customer Service to reserve credit for the Order
  5. The Order Service creates the Order
  6. The Order Service sends a response to the API Gateway
  7. The API Gateway sends a response to the Client


  • Good architecture documentation is essential if you are evolving your application’s architecture.
  • It’s vital that the documentation includes the +1: the scenarios that animate your architecture and show how it relates to your application’s functional requirements.

Copyright © 2023 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.

Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.


Premium content and office hours is now available for paid subscribers at


Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.

Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.

Learn more

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

Remote consulting session

Got a specific microservice architecture-related question? For example:

  • Wondering whether your organization should adopt microservices?
  • Want to know how to migrate your monolith to microservices?
  • Facing a tricky microservice architecture design problem?

Consider signing up for a two hour, highly focussed, consulting session.

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 RESVJCMC to sign up for $95 (valid until September 26th, 2023). 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.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.

Join the microservices google group


Note: tagging is work-in-process

Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  glossary   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  transaction management   ·  transactional messaging

All content


24 Jul 2017 » Revised data patterns