SOFTWARE ARCHITECTURE

Software Architecture defines fundamental organization of a system and more simply defines
a structured solution. It defines how components of a software system are assembled, their
relationship and communication between them. It serves as a blueprint for software
application and development basis for developer team.

Software architecture defines a list of things which results in making many things easier in
the software development process.

 A software architecture defines structure of a system.

 A software architecture defines behavior of a system.
 A software architecture defines component relationship.
 A software architecture defines communication structure.
 A software architecture balances stakeholder’s needs.
 A software architecture influences team structure.
 A software architecture focuses on significant elements.
 A software architecture captures early design decisions.

Characteristics of Software Architecture

Architects separate architecture characteristics into broad categories depending upon

operation, rarely appearing requirements, structure etc. Below some important characteristics
which are commonly considered are explained.
 Operational Architecture Characteristics :
1. Availability
2. Performance
3. Reliability
4. Low fault tolerance
5. Scalability
 Structural Architecture Characteristics :
1. Configurability
2. Extensibility
3. Supportability
 4. Portability
5. Maintainability
 Cross-Cutting Architecture Characteristics :
1. Accessibility
2. Security
3. Usability
4. Privacy
5. Feasibility

SOLID principles of Software architecture :

Each character of the word SOLID defines one principle of software architecture. This
SOLID principle is followed to avoid product strategy mistakes. A software architecture
must adhere to SOLID principle to avoid any architectural or developmental failure.

1. Single Responsibility –
Each services should have a single objective.
2. Open-Closed Principle –
Software modules should be independent and expandable.
3. Liskov Substitution Principle –
Independent services should be able to communicate and substitute each other.
4. Interface Segregation Principle –
Software should be divided into such micro-services there should not be any
redundancies.
5. Dependency Inversion Principle –
Higher-levels modules should not be depending on low-lower-level modules and
changes in higher level will not affect to lower level.

Importance of Software Architecture

Software architecture comes under design phase of software development life cycle. It is
one of initial step of whole software development process. Without software architecture
proceeding to software development is like building a house without designing architecture
of house.
So software architecture is one of important part of software application development. In
technical and developmental aspects point of view below are reasons software architecture
are important.

 Selects quality attributes to be optimized for a system.

 Facilitates early prototyping.
 Allows to be built a system in component wise.
 Helps in managing the changes in System.
Besides all these software architecture is also important for factors that make up a good
software like quality of software, reliability of software, maintainability of software,
Supportability of software and performance of software and so on.

Advantages of Software Architecture

 Provides a solid foundation for software project.
 Helps in providing increased performance.
 Reduces development cost.

Disadvantages of Software Architecture:

 Sometimes getting good tools and standardization becomes a problem for software
architecture.
 Initial prediction of success of project based on architecture is not always possible.
From above it’s clear how much important a software architecture for the development of
a software application. So a good software architecture is also responsible for delivering a
good quality software product.

Types of Software Architecture

Monolythic Architecture

Here the software is designed to provide all system services, including memory management,
process scheduling, and file systems, in a single, large binary. This means that all code runs
in block space, with no separation between code and user-level processes.

The main advantage of a monolithic architecture is that it can provide high performance, since
system calls can be made directly to the without the overhead of message passing between
user-level processes. Additionally, the design is simpler, since all system services are
provided by a single binary.

Characteristics of a monolithic architecture:

 Single Executable: The entire application is packaged and deployed as a single
executable file. All components and modules are bundled together.
 Tight Coupling: The components and modules within the application are highly
interconnected and dependent on each other. Changes made to one component may
require modifications in other parts of the application.
 Shared Memory: All components within the application share the same memory space.
They can directly access and modify shared data structures.
 Monolithic Deployment: The entire application is deployed as a single unit. Updates or
changes to the application require redeploying the entire monolith.
 Centralized Control Flow: The control flow within the application is typically managed
by a central module or a main function. The flow of execution moves sequentially from
one component to another.

Disadvantages

1. Large and Complex Applications: For large and complex application in monolithic, it
is difficult for maintenance because they are dependent on each other.
2. Slow Development: It is because, for modify an application we have to redeploy whole
application instead of updates part. It takes more time or slow development.
3. Unscalable: Each copy of the application will access the hole data which make more
memory consumption. We cannot scale each component independently.
4. Unreliable: If one services goes down, then it affects all the services provided by the
application. It is because all services of applications are connected to each other.
5. Inflexible: Really difficult to adopt new technology. It is because we have to change
whole application technology.
Client Server Architecture

Client-server architecture is a computing model in which the server hosts, delivers and manages
most of the resources and services to be consumed by the client. This type of architecture has
one or more client computers connected to a central server over a network or internet
connection.

A typical topological data flow goes as follows:

1. Client requests data from server
2. Load balancer routes the request to the appropriate server
3. Server processes the request client
4. Server queries appropriate database for some data
5. Database returns the queried data back to the server
6. The server processes the data and sends the data back to the client
7. This process repeats all the requests and services are delivered over a network.

Applicable problems
● The client-server architecture is most useful for applications that require a separation or
abstraction of concerns between the client and the server; it is meant for systems with high
interoperability. The client-server architectural style helps applications improve performance
in scalability.
● In systems that need separation of functionality, the client-server architecture design is most
applicable. Request validation and input could be handled from the client side while the load
balancer routes the request to the server for adequate processing. The server will be responsible
for processing the client’s request, and returning the result via the right protocol. These layers
(client and server) complete tasks independently and they are useful for abstracting
functionality; for example, the client does not need to know how the server handles user
authentication or request validation.
● With the separation of functionality comes the ability of each layer to function more
efficiently at large scale. Modern techniques have been developed within the client-server
architecture to solve scalability challenges like load balancing, sharding, and partitioning. These
techniques provide performance improvements for multiple requests on the server side of the
architecture and will be useful for software programs that deal with multiple requests/users.
Examples of Client Server Architecture

The MVP Architecture:

The MVP architecture is a software development pattern that is used to create applications. It
is a variation of the MVC pattern and is used to create applications that are more testable and
easier to maintain. The MVP pattern is also known as the Presentation Model pattern.

The Model-View-Presenter (MVP) architectural pattern is a derivation of the Model-View-

Controller (MVC) architectural pattern. MVP is mostly used for building user interfaces. In
MVP, the presenter assumes the functionality of the “middle-man”. In MVP, all presentation
logic is pushed to the presenter.

The main advantage of MVP is that it separates the presentation logic from the business logic.
This separation makes it easier to unit test the presentation logic. Moreover, it also makes it
easier to change the user interface without affecting the business logic.

However, the main disadvantage of MVP is that it can make the code more complex. This is
because the presenter now has to handle both the business logic and the presentation logic.

MVC, MVP, and MVVM are the three most popular architecture patterns. They are industry-
recognized and used by many developers. Each has its own strengths and weaknesses, so it’s
important to choose the right one for your project.
The MVP Ideation Canvas is a lean startup framework that helps in defining the key elements
of an MVP (Minimum Viable Product). It provides a structure to define the problem that the
MVP aims to solve, the target customers, the hypotheses you want to validate, and the metrics
you can use to measure your results.

The MVP Ideation Canvas is a valuable tool for entrepreneurs who are looking to build an
MVP. It can help you validate your assumptions about your problem, target market, and
solution. Additionally, it can help you identify what metrics you should use to measure your
MVP’s success.

The MVC Architecture:

There is a lot of software design pattern used for developing any application. During early days
of application development, the approach of designing the User Interface, building the business
logic as well as coding the logic part for the application was programmed and prepared in a
single file which usually created lack of maintenance, make testing of application uneasy as
well as reduce the scalability of any application. To overcome this, a model came into existence
and gradually became popular.

MVC is abbreviated as Model View Controller is a design pattern created for developing
applications specifically web applications. As the name suggests, it has three major parts. The
traditional software design pattern works in an "Input - Process - Output" pattern whereas MVC
works as "Controller -Model - View" approach. With the emergence of the MVC model,
creation of application takes different aspects individually into consideration. These aspects of
the application are:

 UI Logic
 Input logic
 Business Logic

But there is a loose coupling between these aspects or elements. According to this model, each
element needs to exist in an application but not tightly connected or interlinked. The UI logic
deals with the view or front end of the application. The Input logic deals with the controller.
Lastly, business logic deals with the model of an application. This loosely coupled element
helps developers handle development complication when building any application. It helps
users' enables in focus on one specific element of the implementation at a time. Take a scenario
where you are working with business; you can specifically deal with that and focus on the
business logic building without depending on the view logic.

History of MVC
MVC was introduced by Dr. Trygve Reenskaug into Smalltalk-76 programming language when
he visited the Xerox Palo Alto Research Center (PARC) in mid-1970. Later the implementation
became popular in other versions of Small-Talk. Then in the year 1988, the articles in "The
Journal of Object Technology (JOT)" bring the whole picture of MVC as a well-accepted
concept.

The different versions of MVC later came into existence with the requirement for application
designing. These are:

 Hierarchical model-view-controller (HMVC).

 Model-view-presenter (MVP).
 Model-view-adapter (MVA).
 Model-view-viewmodel (MVVM) and some others.

Let us discuss the three components of MVC in brief:

1. Model: The Model encloses the clean application related data. But the model does not
deal with any logic about how to present the data.
2. View: The View element is used for presenting the data of the model to the user. This
element deals with how to link up with the model's data but doesn't provide any logic
regarding what this data all
3. Controller: The Controller is in between the model and the view element. It listens to
all the incident and actions triggered in the view and performs an appropriate response
back to the events.
 Benefits of the MVC Architecture

 Logical clustering of related acts on any controller can be achieved through MVC.
 Various developers can work at the same time on different parts the same application-
controller, model, and the views part.
 In MVC, models can have numerous views.

Micro services Architecture

Microservices architecture has become the methodology of choice for modern application
development. Although it can solve many problems, though, it’s not without its challenges.
That’s why it’s necessary to understand the common design patterns so you can tackle any
orchestration issues with ease.

Let’s take a closer look at microservices architecture patterns, what they are, and how each one
is used.

Microservices design patterns are software design patterns that generate reusable autonomous
services. The aim is to allow developers who use microservices to accelerate application
releases and deploy each microservice independently if needed.
Different microservices patterns each have their advantages and drawbacks. This graphic
demonstrates various design patterns for microservices:

Each service is fully autonomous and full-stack. Changing a service implementation won’t
impact other services because they communicate using well-defined interfaces.

Aggregator

In the world of computing, an “aggregator” is a website or program that gathers and displays
related pieces of data. In microservices patterns, it’s a fundamental web page that calls on a
variety of services to obtain the necessary data or achieve the required functions.

The source of output is divided on breaking the monolithic architecture into microservices. This
pattern can be useful when a developer seeks an output by combining data from multiple
services.

If there are two services, each with its own database, an aggregator with a unique transaction
ID can collect data from each, apply the business logic, and publish it as a REST endpoint.
Then, the data collected can be handed over to whichever respective microservices require it.

API gateway

An API gateway is a variation on an aggregator service. Microservices are known as “the

enabler APIs” in DevOps. Gateways can be a solution to problems such as how to request
information from multiple microservices and how to handle several protocol requests at once.

An API gateway can resolve not only the above concerns but other issues that may come to
light. This microservice design pattern can be considered as a proxy

An API gateway can send requests to multiple services and, in the same way as an aggregator,
send the results back to the composite or consumer service. It can also be the entry point for all
microservices. This creates fine-tuned microserviced API gateways suited to different types of
clients and their needs.

Put simply, API gateways are able to convert protocol requests from one type to another with
the assistance of the API gateway design pattern. They can also offload the microservices’
responsibility for authentication and authorization.

Picture this scenario. A client sends a request. This is passed onto the API gateway, which acts
as an entry point. It then forwards the request to the appropriate microservices. After this, a load
balancer distributes the request to the service. Microservices are thus able to communicate with
each other via a stateless server i.e. either by HTTP request or message bus.
Asynchronous

An asynchronous microservices design pattern calls for all services to communicate with each
other. However, this doesn’t have to be sequential. You can use various microservices software
architecture patterns and techniques to create this.

So, out of three services, the client’s request may be sent to two simultaneously. These requests
will be put in a queue. The request can also be sent to the other service, but it doesn’t require
the response to be sent back to the service it came through.

Asynchrony can be achieved, but this is carried out in an application-specific way. Some
microservice architectures may choose to use message queues instead of REST
requests/responses because of this.

Backend for frontend

Backend for frontend, also known as BFF, is a variant of the aforementioned API gateway
pattern. It provides an additional layer between the client and microservices.

It isn’t a single point of entry. Instead, BFF introduces multiple gateways for each client. With
this approach, you can add an API tailored to their specific wants and needs. This can remove
much of the hassle caused by keeping this all in one place.

Note that this pattern may be extended for particularly complex apps. Different gateways can
also be created for certain business domains if needed. Developers often prefer this model as
it’s flexible and can be used to respond to most microservice situations.

A backend for frontend approach provides extensive business capabilities. Not only this, but
it’s ideal for the continuous delivery of microservice architecture on a large scale.

However, this doesn’t mean every microservices-based architecture should use a BFF pattern—
as we’ve discovered, not every pattern resolves every situation. The more complexities there
are in the design, the more setup is required.

Remember when creating a variety of apps that you may want to choose a more complex
communication pattern than you need to enable scaling up in the future.
Branch

As we’ve seen, a microservice might need to pull data from multiple sources, which can impact
data consistency. Sources of data can include other microservices, so the branch microservice
pattern is a mix of aggregator and chain design patterns.

What this means is it can accept requests and responses from two or more microservices at the
same time. Additionally, branch patterns can be used to invoke different chains of
microservices, or a single chain, based on the business’s needs.

Chained

A chained microservice design pattern produces a single response to a client’s request. For
example, a request may be received by service one. This then communicates with service two.
In turn, number two could be communicating with service three. These services will likely all
be using synchronous HTTP request/response messaging.

Circuit breaker

When remote calls fail or hang without a response until a timeout is reached, the solution is a
circuit breaker. If you have a lot of callers and a supplier who doesn't respond, you might run
out of important resources, which could cause failure across the applications' systems.

This is when a circuit breaker pattern comes into play. The circuit breaker trips when the number
of failures reaches a certain level, and any subsequent calls to the breaker result in an error, a
different service, or a default message instead of the protected call being made.

Client-side UI composition

When services are developed by breaking down business capabilities, dependencies, and
subdomains, the services responsible for the user experience have to pull data from several
microservices.

Previously, there used to be just one call from the UI to a backend service to collect all data and
refresh or re-submit the UI page. Nowadays, however, this isn’t the case.

With microservices, the client-side UI has to be designed as a skeleton with multiple sections.
Each of these areas will make a call to an individual backend microservice to pull up the data
on the screen. Frameworks like AngularJS and ReactJS can help developers do this.
These screens are known as single-page applications or SPAs. Each team of developers creates
a client-side UI component that handles the region of the page/screen for their service.

A client-side UI composition team is then in charge of implementing the complete page

skeletons. They do this by composing multiple, service-specific UI components.

Database per service

In some use cases, one database per microservice must be designed. This should be private to
that service. It’s thus accessible by the microservice API only and can’t be directly reached by
any other services.

For instance, for relational databases, you can use private tables per service, schema per service,
or database server per service.