What should come first when designing a software architecture, and what should be taken into account unconditionally? For all my experience, I faced multiple architecture challenges and collected a luggage of valuable insights, which now help me plan and design accurately from the start and avoid mistakes afterward. Want to learn some of them? Here are 5 takeaways I would like to share with you in a simple and a bit hilarious way.
Before you start thinking about architecture
Prior to building any software architecture, study the business domain where the new application will be used. It’s crucial to understand the customer’s requirements, end users, and how exactly the product should simplify their work.
For clarity, let’s take a customer who wants to order a “vehicle”. Task number one will be to find out if they want a scooter, a car, an airplane, or a rocket. Imagine we’ve defined that the order is a car. At this stage, don’t forget about the project budget. When you read books and articles on programming, it seems that the budget is always unlimited and nothing prevents you from creating the best product in the world. In reality, this is usually not the case, and the task is to do the maximum for time X and budget Y.
In our example, this all refers to the class of the car - whether the customer wants a subcompact car or a sports car.
Cloud vs. on-premises
Step number two is to choose the application deployment option–cloud or on-premises. It may not be so important when selecting an architecture pattern, but it’s useful for understanding what tools и services you have in place, to consider all specifications and limitations in advance.
Applied to our example, it means the roads which the car will be driving on.
Why do we need a proper architecture?
Compliance with the business requirements is wonderful, but not enough. Here’s what the architecture should provide additionally to meet the customer’s needs:
- Simple maintainability
- Possibility to easily add new functionality
- Clear and user-friendly interfaces, both user and programmable (API)
We want a minimum of problems after the sale of the car: oil change once a year and that's it. However, we must ensure easy diagnostics in case of a breakdown. Functionality is a different thing. For example, if a client wants to replace the radio mechanism–not a problem, this option is available. But if the client wants the car to fly, this was not supposed by the initial requirements.
Most common architecture patterns in my practice
The most commonly used patterns are:
- Client-Server - Classic (old-school) splitting an application into the two main components.
- Multi-layered architecture (or n-tier architecture) - Splitting into levels. The simplest version is splitting into Data, Business, and Presentation layers.
- MVC (Model-View-Container) - User-interface oriented pattern, often used in the development of web applications.
- Microservices - Splitting an application into many small services that interact with each other to implement business applications.
- DDD (Domain Driven Design) - The pattern based on business entity partitioning.
It would be incorrect to apply the patterns above to the “vehicle” example, but very conditionally and rather as a joke, it can be done like this:
Closing remark
You should understand that in practice, application architecture typically represents a mix of several patterns. It occurs when one service has many levels inside, or when some services (components) are business entities while others are not.
.svg)
