Software Architecture Patterns
Software comes in all types of size and shapes. Every team has different though process, works differently and the outcome of the software depends upon various factors such as client requirement, budget, time, use of available solutions to common problems etc. And if all goes well, the application does what the user expects it to do. But modern software can be complex, which can lead to complex code. And complex code is difficult to work with. What if we could make software easier to work with? What if we could translate complex architectural problems to recognizable patterns?
Just like a mechanical engineer will recognize many of the parts that make a machine, the software engineers can build software using tried and tested patterns. Knowing and applying the patterns allows us to reduce the complexity (of maintenance) and work more efficiently. Knowing different patterns helps to create faster, more reliable, and simply better applications.
Patterns can be quite complex to understand initially but once you start recognizing common solutions to common problems, it gets easier to work with the patterns.
But what exactly are software architecture patterns?
A pattern in software is basically a solution to a common problem. If you are facing a problem, you might be able to solve it by applying the existing solution. Different components and the way they interact with each other in a pre-defined manner defines a pattern.
We can compare it to writing. If you want to bring across a message, you can just start writing saying whatever comes up but that would not help in communicating your message. You could do better by structuring your text with an introduction, body (which may include advantages and disadvantages), and conclusion.
Or we can compare it to movies which follow what is called a three-act structure.
First, the characters are introduced and then they come together.
Secondly, there is the actual adventure where the characters work towards a goal.
And finally, there is the big finale in which they achieve the goal.
What most developers think about when they hear the term software patterns are things like the Repository pattern, the Singleton pattern, the Builder pattern, or the Factory pattern and there are many more. These are patterns that define how to write and interact with certain classes.
The Repository pattern
The Repository pattern, for example, shows us how we can abstract the way implementation details on how to retrieve data from a database. A piece of our application would call a repository class, which contains the logic to build and send a SQL query to the database. It also contains the logic to translate the database response to the format that the application code will understand.
The TryParse pattern
Let us look at another example. To parse a string into an integer in C#, you can use the following code:
int x = int.Parse(5)
This will return an integer. But what happens if we use a string that does not represent the number? Like
int y = int.Parse(“hello”)
This will throw an exception. If we are not sure about the input, we can use the TryParse method like this.
int z = zero;
if(int.TryParse(input, out z))
\\Your logic here
The above code will not throw an exception if it cannot parse the input. This is sometimes called the TryParse pattern. You provide an API that contains a parse and the TryParse method. The convention then states that the parse method cannot throw an exception if it encounters something that it cannot parse. But the TryParse method should not throw an exception. It will return false if it cannot parse the input. And if it can, it returns true and sets the value of the out parameter. We call this a pattern because it features on other .net classes and structs as well. This makes it recognizable for many .net developers. So, we can encounter patterns on all levels in software.
When we talk about software architecture patterns, we are looking at how applications are structured on a higher level. The line is not always clear, but we are looking beyond the single class level to use an object-oriented term. We are not focusing on how to write and interact with a single class. Software architecture patterns will show us how we can structure and interact with multiple classes in our application. We could even go up a level and identify patterns that show us how to organize multiple independent applications, regardless of how those are structured internally.
Need for software architecture patterns?
Can’t we just write code and see how it evolves? Well, using known patterns has significant advantages. We can compare it to the blueprint of a house. You can build the house without it, and you might end up with something okay. But if you build something bigger and more complex, you will want a solid plan. This way, you can build something that will last longer.
Advantages
Makes Code recognizable to the other developers: Using known patterns will make your code recognizable to other developers who join the project later. This makes it easier for them to get up to speed, which is better for the entire organization. Senior developers need to spend less time coaching and the newcomers can become productive more easily.
Often these patterns are also easier to maintain and extend. They are using the collective experience and wisdom of many developers that proceeded you. The patterns are featured in many pieces of literature and documentation. So, if you have any questions about them, it is easy to find information. Knowing several software architecture patterns means you can apply them to your projects.
Helps decision making process: It allows you to weigh the pros and cons of taking different approaches and it can help identify improvements you can make to the current architecture of your projects.
Increases productivity: All these points allow you to become a more productive member of the team and they make the team more productive.
Caveats
Other Solutions available: This does not mean that a specific pattern will be the only solution to your problem.
Does not guarantee that a certain pattern will help you. It is just that for similar problems, certain patterns have proven to be extremely helpful.
It gives you just a good starting point. If a chosen pattern proves to be a bad solution in your case, then you can take a different approach.
But even with these possible dangers, software architecture patterns are worth it. They will make your applications better and you as a developer as well.
Software design patterns vs Architecture Patterns
There is a difference between software architecture patterns and software design patterns, so it is useful to know the line that differentiates them.
Design patterns define a small number of components that can be used in an application. They do not describe how the application should be built. Design patterns only tell us what a specific piece of code must do, and how other pieces of code should interact with it. For example, the factory pattern tells us that we can write a customer factory class with the create method. A factory then has all the complex logic of creating a customer. Any other piece of code that then needs to create a customer can just call the customer factory. But this pattern does not say anything about how other pieces of the application should be structured.
Software architecture patterns occur at a higher level. We are no longer looking at a small piece of the application, but at what defines the application or at least a significant part of it. This means we will often be looking at multiple components and their interactions. And in this case, many of these patterns can be implemented in different programming paradigms — Procedural, object-oriented, or functional.
For example, will we structure our application in distinct layers, or should we split it up into multiple independent processes on physically separated servers? And if we do, should they communicate over a central messaging system or directly with each other? Software architecture patterns will give you a holistic view of how you can develop your applications.
Design Pattern: Circle, Rectangle, Square all use a common Shape Factory to create an object.
Architecture Pattern: The following diagrams specify how the components interact with each other. The components can be in different languages, can use different design patterns and can process the data differently.
Pattern 1 — The components use a central messaging system to interact with each other. There is no direct communication between the components. The messages are queued, and components are notified when a new message is added to the queue.
Pattern 2 — The components interact directly with each other and does not use a common messaging system. The interaction is synchronous, and components send and receive messages without queuing the messages.
Categories of patterns
Just like with anything in software development, there are many ways we can categorize the software architecture patterns. Unlike software design patterns, where there is an agreed-on categorization, software architecture patterns do not have that shared understanding as much. So, keep in mind that each architect has a different way of looking at these patterns.
We can categorize them into three main categories.
· Application landscape patterns
· Application structure patterns, and
· User interface patterns
For e.g. Let us say we are designing a suburb. We start out by planning the suburb, things like where the house sizes, trees, parks, shopping area, road sizes, and the roads between them. Once we have that designed, we can move into designing the individual house. So how many rooms, what kind of garden etc, and finally getting into the details with how the people get in and out the house, plan things like door size, shape, colour, and so on.
The suburb is like the application landscape pattern. These are software architecture patterns that help us create a single application as it is viewed by the end user. Keep in mind that the end user can be a human but can also be another application. The application can consist of multiple other applications behind the scenes, but this will be hidden from the end user.
Following are the application landscape patterns
o Monolith,
o N-tier,
o Surface-oriented,
o Micro-services,
o Serverless,
o Peer-To-Peer.
It is all about how multiple applications work together to support a single application. But then how do we design those individual applications? That is application structure patterns, which are kind of like the individual houses in the suburb. Application structure patterns are a category of patterns that define how a single executable should be built. So, it is about the structure of a single executable. This single executable can be the entire application as the end user views it, or it can be a smaller part of a larger landscape.
In this category, we will look at the
o Layered pattern,
o The microkernel,
o Command Query Responsibility Segregation or CQRS,
o Event sourcing,
And the last step in designing our suburb is getting into the details of how the user gets into the house, the front door. This is user interface patterns. It is about how the user interacts with the actual application itself. These could be regarded as mere software design patterns, but they consist of multiple components and they can define a large part of an application. In some cases, the UI is the application, so we can regard them as a separate category of software architecture patterns.
We will be looking at
o Model-view-controller,
o Model-view-presenter,
o And model-view-view model.
In the upcoming articles, I will try to cover each one of the patterns mentioned above in detail. I will try to elaborate as much as I can.
Wrap-up
Thanks for reading. Share to give this post some love if you found it helpful.
Thanks
Jatinder
