Software architecture is something that is hard to define in a single statement. However, to summarize, the architecture of an application is its whole design, together with how its blocks/modules/layers interact with each other and with the related documentation.
As explained in the previous chapter, different designs produce different pros and cons in terms of the various aspects of performance. Here, we will dive into the most used/misused architectural techniques and solutions, in search of the best for our performance goals.
In this chapter, we will focus on the following topics:
- Software architecture
- Performance concerns about the architecture
- Object-oriented design principles
- Common designs and architectures
- Common platform architectures
- Performance considerations
A software architecture is something a development team must share, together with the person in charge of the architecture itself (even better if someone who constructs software architectures as their main job), to achieve the goal of producing an application with standard methods, techniques, and tools driving the team as standardized industry-level workers.
A software architect is someone who designs software in a real sense. He understands and addresses business (functional) and technical (non-functional) requisites that drive the development team in the right direction during the entire software development lifecycle. A software architect is also someone who makes the software writable by multiple developers simultaneously, by writing a global design at the beginning of the development of a new software, and hence, enables it to work homogeneously. This is why, often, a software architect is in charge of internal framework development, and so, useful in simplifying and standardizing team working.
This happens by writing documentation about overall architecture and design, defining all boundaries that any module must comply with, all technologies to be used by those modules, all standards to apply to, any authentication and authorization logic, and any choice about the interaction between those modules or layers depending on the kind of application.
Note
Software architecture: A widely accepted definition of software architecture is that it deals with anything that software developers perceive as hard to change. As foundations are unchangeable once we build the building, the same applies to those guidelines and rules that build software architecture. Software architecture is not about technical whole-application level choices; it is the art of making a choice.
Although creating multiple modules in an agnostic way and never trying to fulfill single specific business needs, such modules may help the company to reuse the software by creating a corporate code base. However, dividing software into multiple modules does not imply architecting it. Different designs and patterns also exist regarding architectures. Any of those designs can alter some project management rate, such as future code reuse (productivity), maintainability, or performance.
At the design stage, anything can produce pros and cons regarding all three different sides of the same cube, which represents the whole work of software development. Architectural decisions affect performance in a way that is sometimes hard to fix with simple future optimization code; so always be particularly careful in the design stage.
In this context, performance thoughts are usually a primary concern. Sometimes the choice of having less manageability instead of a higher throughput can be taken, or vice versa, if that is the need. However, choices such as writing ugly code in the name of extreme performance are usually something to avoid.
Software architecture is some kind of multipurpose design of the whole system, where different decisions are made to fulfill the right balance between all needs and specifications, including performance that a software actually needs. The software should also eventually support future additions/modifications.
A big deal when designing the architecture is the use of design patterns.
The most diffused definition of pattern (applicable also to software patterns) is the following one made by Christopher Alexander in his book A Pattern Language: Towns, Buildings, Construction, published in year 1977:
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
Always remember that a software architecture is not a design pattern, although a design pattern (usually multiple) may become a part of a software architecture. A design pattern is a commonly used solution to a commonly faced problem. Though the definition is simple, the most important aspect of design patterns is their ability to standardize the market regarding how professionals talk to each other. Talking in terms of patterns between professionals helps one understand it technically. For instance, saying, I made a layered architecture, helps—it avoids always explaining what a layered architecture is. The same can happen when, instead of saying, I prepared an instance of a class to be used in any case and from anywhere, a professional simply says, I made a singleton of such class.
Thus, outside this, the only reason is to choose a design pattern, simply create your own, or use no design pattern, is the need to develop the software. Sometimes, the market enforces its fashions, such as the use of Model-View-Controller (MVC) or Model-View-ViewModel (MVVM) patterns. An example is Microsoft's development web environment: since ASP.NET in 2010, MVC has become the standard for web applications. As a pragmatic developer, I can only state that this does not mean that Web Forms is dead and that we cannot use it anymore in the future! Both MVC and Web Forms have different pros and cons, and the choice of which fits our software best should be the only (or principal) motivation to adopt one web presentation pattern over another.