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.
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
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.
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:
Create Orderrequest to the
API Gatewayproxies the request to
Order Serviceinvokes the
Restaurant Serviceto validate and price the
Order Serviceinvokes the
Customer Serviceto reserve credit for the
Order Servicecreates the
Order Servicesends a response to the
API Gatewaysends a response to the
+1: the scenarios that animate your architecture and show how it relates to your application’s functional requirements.
Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
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 JUNVCEJE to sign up for $195 (valid until February 1st, 2023). There are deeper discounts for buying multiple seats.
Chris offers numerous resources for learning the microservice architecture.
Chris teaches comprehensive workshops, training classes and bootcamps for executives, architects and developers to help 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.
Delivered in-person and remotely.
Want to see an example? Check out Chris Richardson's example applications. See code
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
Use the Eventuate.io 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.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · dark energy and dark matter · deployment · development · devops · docker · implementing commands · implementing queries · inter-service communication · loose coupling · microservice architecture · microservice chassis · microservices adoption · microservicesio updates · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · team topologies · transaction management · transactional messaging