Software Architecture Diagram Types

I am moving the blog to
In the next months, I will close this one.

In this article, I’ll try to explain some software architecture diagram types. This will not be a comprehensive guide of all the types of software architecture diagram available, but I hope that it will help you in representing the architecture of your software.

What is a software architecture diagram?

First of all, we need to make clear what a software architecture diagram is: simply put, it is a representation of how things work in a software.

There are a lot of ways to represent a software architecture. I know 3 ways to do it:

  • Conceptual Architecture Diagram
  • UML Diagrams
  • C4 Model

Conceptual Architecture Diagrams seem simple, but they are not. Basically, they represent the “big picture” of a software/system. Looking at it, the reader can immediately grasp how things work even in a very complex system.

UML (Unified Modelling Language) is really big (and probably this is the reason it is not used so often), but with just one or two diagrams we can do a great job in explaining our software architecture. Even today, when I need to explain how things work in a software, I draw an improvised Communication Diagram. In this way, I can give immediately an idea of the components, the relationship between them and how they interact each other. I am not a fan of Sequence Diagrams because I find they promote “procedural code” instead of allowing me to create “OO code”, but they are effective too (and by the way that was another story :D). In the last 10 years, I used just those 2 diagrams and sometimes the Use-Case Diagram. I don’t see a Class Diagram since 2005 and never seen used any of the other diagrams.

C4 Model is the most recent one. It represents the overall architecture using multiple views of it.

  1. Context diagrams: show just the systems and the relationship between each other. It gives you the “big picture”
  2. Container diagrams: decompose a system into containers (e.g. an application, …)
  3. Component diagrams: decompose a container into components, and relate the components to other containers or other systems
  4. Code diagrams: provide details about the design of a single component

To me, it seems an improvement of an old diagram called 4+1 architectural view model.
I have never used the C4 Model, so I won’t talk much about it, but I am pretty sure that combining a Conceptual Architecture Diagram with others diagrams mentioned in UML, you can reach almost the same result provided by C4 Model.

What should be included in software architecture diagram?

In a software architecture diagram, what you should include depends on the diagram and the type of diagram to choose depends on the audience.
Here some examples of what you should include.

This is an example of a Conceptual Architecture Diagram:

Conceptual Architecture Diagram

As you can see, at the center you have the core software mentioned as “Security Manager”, while on the edge you can see “external” parts such as (in this specific case) languages (on top left) that could use the software, databases (on the bottom), LDAP, etc… In the center, the software is composed by internal blocks that are shown in order to give the reader an idea of what the architecture contains. You can see also some interaction between some internal components and external parts (for example the arrows between “Cache” and the RDBMS) that could be used to reason implementation details worth to mention.

The following diagram is an example of Communication Diagram (that in older versions of UML was named Collaboration Diagram and even today you can find it with this name):

Communication Diagram

This diagram can be found on (I suggest to take a look to that website, because it is really good in explaining UML).
The example contains a lot of blocks, labels, colors, etc…, but just to make things really simple, you have to remember one thing in order to draw a good Communication Diagram:

draw the main components of your software as blocks and connect them specifying also the sequence of execution

That’s it. Pretty straightforward. I never have the need to make it tool complex. Also because, if it becomes too complex, it means 2 things:

  1. you are explaining too many details
  2. your design is really too complex

For 1. I have one tip:

when you draw the components, this doesn’t mean that you have to draw all objects used by your software to work. You can draw just the main components. Leave the details to the code or to others diagrams (e.g. the Sequence Diagram, the Class Diagram, etc…)

For 2. pay attention, because sometimes a Communication Diagram can give you some hints on what is wrong in your architecture: maybe you can see in front of your eyes that there is a component that is not needed. On the other side, sometimes when you translate in code a design made on paper, it won’t work because coding is a totally different beast.

The last example is a Sequence Diagram:

Sequence Diagram
Sequence Diagram

This is a very simple Sequence Diagram, but it is good for explaining how it works.
On the left, you can see the operation checkEmail called on Computer. When this happens, Computer calls sendUnsentEmail of Server. After that, it calls newEmail of Server waiting for a response. The next steps can be read by the reader as an exercise.

I have always considered Communication Diagrams more maintainable when compared to Sequence Diagrams, if you like to draw them by hand. But nowadays, there are a lot of free software to draw Sequence Diagrams that can be updated in a couple of seconds (I’ll mention them in the next paragraph).
One thing that I noticed in my career is that, when people asked to see a Sequence Diagram of a piece of code, I could bet that the code was full of code smell or unmaintainable or unexpectedly complex 🙂

How to draw a software architecture diagram?

In order to draw a software architecture diagram you can use some software freely available, but I’d not refuse to draw them by hand. For example, I liked to draw a communication diagram while explaining the architecture of a software to a new team member.
In the next paragraphs, I’ll mention some free software I found pretty simple to use: (online): it was known as few years ago. It is really good to draw all software architecture diagram types, but I’d use it mainly for Conceptual Architecture Diagrams and Communication Diagrams.
For Sequence Diagrams I found alternatives that are far simple than

Dia (installation): I would say that with Dia you can probably create any diagram. Really. If you look at the screenshots section of the website, you’ll see that I am telling the truth 🙂

Violet UML editor (Eclipse plugin): I used this in the past as an Eclipse plugin. I remember it was doing a good job, but I never had the chance to try it in my last job (so almost 7 years :D). I cannot give any feedback about the more recent versions.

ArgoUML (installation): I used ArgoUML a lot in the past. It is really good. You can write all UML diagrams with it. It is available since 1998… more than 20 years! The link I put is the Github project so that you can then find the right way to install it on you computer.
The UI is made with Java (I think Swing) so it can work on any desktop.

In conclusion

There are plenty of software architecture diagram types.
Choosing the right one is a matter of audience.
Non-technical people will be glad to view a Conceptual Architecture Diagram of your software. Technical people will be glad to view a Communication Diagram (or a Sequence Diagram) in order to understand how it works.

“Let the domain drive” architectural pattern

One of the most helpful concept I learned in my career is the Hexagonal Architecture.
I started using it in green-field projects and I was very happy with it.
After years, I changed my job and went in a so called “agile” company.
Some projects were in a very bad shape… but also new projects had something weird.
And the funny thing was that people working on those new projects were telling me that they were using the Hexagonal Architecture.
They were right: the Hexagonal Architecture was there… but I didn’t recognize it. And the reason was that it didn’t match my style!

Basically, what I found was that:

  1. sometimes the domain objects were not “mentioned” on ports: there were other objects… a kind of anti-corruption-layer (ACL) in between the domain and the ports
  2. the adapters had new objects equal to the domain ones, but not totally… they had some differences here and there… and there were mappers between the domain objects and those duplicate objects
  3. the domain objects were highly protected by “everything”. They were living in a specific module. The adapters were in another module with their objects very similar to the domain ones. If you have to add something to domain objects you were pretty sure you’ll have N other changes to apply (where N is the number of ports in your software)

In the future, I’ll share some techniques we used to refactor those applications.
But in this post, I want to share an improvement to the Hexagonal Architecture that add an additional principle.
I think this architectural pattern is already known by expert OO programmers… probably it is obvious for them, but it has no name, it is not mentioned, and lots of colleagues (even experts not only novice or advanced beginners…) create architectures with the issues mentioned above, so… I decided the name 😀

It’s called “Let the domain drive” architectural pattern.
The added principle is: “if you have to share the state of an object, you strive to share it without polluting your application with duplicated objects”.
Does this mean that your domain objects are in trouble?
No, when you realize that they are in trouble because of “external influences” that could make them “dirty”, you can act duplicating objects… but you have to be sure you need it (YAGNI).

How to handle the known issues mentioned

Now I’ll look at the findings mentioned above and I’ll try to explain how to handle those issues with this architecture.

Issue 1: domain objects not used in ports

This is simple.
It is an error even if you are using the Hexagonal Architecture.
So, please fix this.

It seems someone around the world think that you can have DTOs in the ports.
Just as an example, here you can find an article by Matteo Vaccari on the The Birthday Greetings kata. Do you think it’d be acceptable having the EmployeeRepository returning a List<EmployeeDTO>? Why not the List<Employee>? Employee is the domain object here. Why do you need to use that DTO? Do you have a reason? if the reason starts with “because if in the future…” STOP: YAGNI

Issue 2: adapters with objects very similar to the domain ones

In the “Let the domain drive”, you strive for having only and only the domain objects. Objects that are similar to the domain ones should be used only if you are already sure that the state of your domain objects cannot be “shared” externally.
If YAGNI, you stick with just your domain object.

Issue 3: touching 1 object requires N other objects to change (where N = ports)

In the “Let the domain drive”, you remind yourself being a software engineer.
With this in mind, when you realize that there is a repetitive task/action… a common pattern… something that could become a “liability” in the future, you start applying different techniques to handle automatically those things.

For example:

  • Storing objects automatically using reflection
  • Creating new “objects”/”map”/”things to share with external systems” automatically using reflection or “describing how” in the domain object using syntactic metadata (e.g. Java annotations)
  • Generating code

Everything is allowed if you are not polluting the domain objects with “technical stuff” at the same abstraction level of “domain stuff”.

Just to give you an example found for real (I changed just names). If you have a domain event such as:

public final class ProductPurchasedEvent extends EventObject {
private final Product product;
private final Price price;


and you have to store the event in JSON, you could create new objects ProductPurchasedEventJson, ProductJson, PriceJson and make the mapping manually. This approach is not consistent with Simple Design and by the way it costs a lot in maintenance!
Repeat this approach every time you have this kind of problems and you have just confirmed that you are not a programmer, but a creator of liabilities in your company.
Your company should sue you… just joking (or maybe not).

In the “Let the domain drive” architecture, at the beginning you’ll try to “serialize” the entire object in JSON. Then, if you realize that you can share only parts of the state of your domain object you could add Java annotations to prevent sharing everything or maybe you already have parts of the object that should have been marked as transient

Remember that you are an engineer.
And I am pretty sure you’ll find a solution for your specific case.

What does “Drive” word stands for?

We talked mainly about technical stuff, but “Let the domain drive” architectural pattern is a matter of creating a product with a simple design.
So the real job starts when you have to evolve an object that is in trouble because someone is going to mix data with different meaning in the same place (such as technical data with domain data).

I am going to give you an example. Imagine that you have a domain object representing a product purchase. You mapped automatically that product purchase from a payload of a REST call. Now they need to put a trace id of the HTTP request. If they put that trace id in the payload, your domain object will be in trouble.
you suggest to use a different place to put that trace id, such as (for example) the HTTP header.

This is how you use that “Drive” word.
Your architectural decisions are handled in order to keep the design simple without polluting the application with useless objects and without mixing data.
This is a very simple example, but it is because the entire idea is simple.

What if someone forces you to put that trace id in that payload?

Then, it is time to protect your domain object, but I’d share with the people forcing you that your project will start to cost a little bit more than the solution you suggested. And I’m not joking! It will cost more for sure!

PROS of “Let the domain drive” architectural pattern

  • You’ll have just one object to represent something with just one name (more symmetry and consistent with the 4th element of simple design)
  • You’ll be fast in embrace changes (reduced costs of changes)
  • You’ll understand the code better and faster (clean code)
  • You can apply it even on legacy code, because you have to accept different approaches for each domain object…

CONS of “Let the domain drive” architecture

  • You have to protect your domain objects. If you have junior programmers (or programmers that are not really “clean”), they won’t realize when it is time to break the usage of this style because it is no more suitable
  • Watch for over-engineering. As an example: I have seen people starting with a simple system to store objects automatically on DBs ending with a kind of home made Hibernate or a home made Spring Jdbc. You should remind yourself that the solution should be cost effective
  • You could have different approaches for your objects. Maybe an object can be shared automatically and another one requires a manual mapping. I met people that rather prefer to use the same approach everywhere instead of reducing the duplicated objects.
    If this kind of situations, you’ll have difficulties with this architectural pattern.
  • When a programmer uses this architectural pattern, he’ll have difficulties in going back to the previous approach. His life as a programmer will be ruined 😀

Remember: the aim of this architectural pattern is not to have “a standard way to approach *any* design or every part of your design”, but to stay as much as you can with your domain objects in every part of your application, “disconnecting from them” only when you really need.