SOFTWARE ARCHITECTURE PATTERNS

INGEGNERIA DEL SOFTWARE

Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica

[email protected]
SUMMARY
○ Introduction
○ Layered architecture
○ Microservices architecture

Ingegneria del software Riccardo Cardin 2

INTRODUCTION
○ Applications lacking a formal architecture are
generally coupled, brittle, difficult to change
● Modules result in an unorganized collection
● Big ball of mud antipattern
● Deployment and maintenance problems
○ Does the architecture scale? How does application response to
changes? What are the deployment characteristics?

○ Architecture patterns
● Helps to manage these aspects, knowing the
characteristics, strengths and weakness
Ingegneria del software Riccardo Cardin 3
LAYERED ARCHITECTURE
○ Most common architecture pattern
● N-tier architecture pattern
● Standard de facto for most JEE applications
○ Widely known by most architects and developers
● Reflects the organizational structure found in most IT
companies

○ Components are organized into horizontal layers

● Each layer performs a single and specific role
○ The most common implementation consists of four layers
○ Presentation, business, persistence and database

Ingegneria del software Riccardo Cardin 4

LAYERED ARCHITECTURE

Ingegneria del software Riccardo Cardin 5

SEPARATION OF CONCERNS
○ Every layer forms an abstraction over a particular
business request
● Components within a specific layer deal only with
logic that pertains to that layer
○ i.e. Presentation layer does not need to know how to get
customer data
○ Component classification makes easy to build
effective roles and responsibility models
● Limited component scopes make easy to develop, test
and govern , maintain such applications
○ Well defined component interfaces
Ingegneria del software Riccardo Cardin 6
KEY CONCEPTS
○ Layers should be closed (layer isolation)
● A request move from one layer to the layer right
below it
● Changes made in one layer generally don’t impact or
effect components in other layers.
○ Layers can be open, too
● Imagine a service layer below the business layer that
offers commong services.
○ The business layer should go through the service layer to
access the persistence layer.
○ Making the service layer open resolve the problem
○ Open layers should be very well documented

Ingegneria del software Riccardo Cardin 7

KEY CONCEPTS

Ingegneria del software Riccardo Cardin 8

EXAMPLE
Example
Consider a request from a business user to retrieve customer
information for a particular individual

Accepts the requests, routes

them to business layer and
display information

Aggregates all the information

needed by the business request

Executes SQL statements to

retrieve the corresponding data
and passes it back up

Store information in a persistent

form

Ingegneria del software Riccardo Cardin 9

CONSIDERATIONS
○ A good starting point for most application
● It’s a solid general purpose pattern
○ Architecture sinkhole anti-pattern
● Requests flow through multiple layers as simple pass-
through
○ 80-20 proportion of good paths wrt sinkhole path
○ Open some layer (but be aware!)
○ Tends to lend itself toward monolithic
applications
○ It could be an issue in terms of deployment, robustness and
reliability

Ingegneria del software Riccardo Cardin 10

PATTERN ANALYSIS
Characteristic Rating Description
Small changes can be properly isolated,
Overall agility big one are more difficult due to the
monolithic nature of the pattern
Difficult for larger applications, due to
Ease of
monolithic deployments (that have to be
deployment properly scheduled
Very easy to mock or stub layers not
Testability affected by the testing process
Most of requests have to go through
Performance multiple layers
The overall granularity is too bread,
Scalability making it expensive to scale
A well know pattern. In many cases It has
Ease of
a direct connection with company’s
development structure

Ingegneria del software Riccardo Cardin 11

MICROSERVICES ARCHITECTURE
○ A still evolving pattern
● A viable alternative to monolithic and service-oriented
architecutures
● Separately deployed unit
○ Easier deployment, increased scalability, high degree of
decoupling
○ Service components
● From a single module to a large application’s portion
○ Choose the right level of service component granularity is one
of the biggest challenges
● Distributed: remote access protocol
○ JMS, AMQP, REST, SOAP, RMI, ...
Ingegneria del software Riccardo Cardin 12
EVOLUTIONARTY PATHS
○ Evolved from issues associated with other
architectures
● From monolithic: open to continous delivery
○ Avoid the «monthly deployment» cycles due to tightly
coupling between components
○ Every service component is independent developed, tested
and deployed

● From SOA: simplification of the service notion

○ SOA is a powerful pattern, that promises to align business
goals with IT capabilities
○ Expensive, ubiquitous, difficult to understand / implement

○ Eliminates orchestration needs, simplyfing connectivity

Ingegneria del software Riccardo Cardin 13
THE PROBLEM OF SCALING

Ingegneria del software Riccardo Cardin 14

THE PROBLEM OF SCALING
○ The monolith scales only along the x- and z-axis

Ingegneria del software Riccardo Cardin 15

THE PROBLEM OF SCALING
○ Microservices uses functional decomposition

Ingegneria del software Riccardo Cardin 16

MICROSERVICES ARCHITECTURE

Ingegneria del software Riccardo Cardin 17

API REST-BASED TOPOLOGY
○ Useful for websites that expose small services
● Service components are very fine-grained
○ Specific business function, independent from the rest
○ Only one or two modules

○ Microservice

○ These services are accessed through and API

● REST-based interface
○ Separately deployed web-based API layer
○ Google, Amazon, Yahoo cloud-based RESTful web services

Ingegneria del software Riccardo Cardin 18

API REST-BASED TOPOLOGY

Ingegneria del software Riccardo Cardin 19

REST-BASED TOPOLOGY
○ Accessed directly by fat / web based clients
● User interface is deployed separately
● REST-based interface
○ No middle API layer required

○ Larger and coarse-grained

● Represent a small portion of the overall business
application
○ Common for small to medium-sized business applications

Ingegneria del software Riccardo Cardin 20

REST-BASED TOPOLOGY

Ingegneria del software Riccardo Cardin 21

CENTRALIZED MESSAGE TOPOLOGY
○ Lightweight centralized message broker
● No trasformation, orchestration or complex routing
○ Not to confuse with Service-oriented application
● No REST-based access required
● Found in larger business applications

○ Sophisticated control over the transport layer

● Advanced queuing mechanisms, asynchronous
messaging, monitoring, error handling, ...
● Broker clustering and federation
○ Avoid the architectural single point of failure and bottleneck

Ingegneria del software Riccardo Cardin 22

CENTRALIZED MESSAGE TOPOLOGY

Ingegneria del software Riccardo Cardin 23

SERVICES GRANULARITY
○ The main challenge is to defined the right
granularity of service components
● Coarse-grained services
○ Not easy to deploy, scale, test and are not loose couples
● Too fine-grained services
○ Require orchestration, turning into SOA application
○ Require inter-service communication to process a single
request

○ Use database communication

● Avoid service-to-service communication

Ingegneria del software Riccardo Cardin 24

SERVICE GRANULARITY
○ Violation of the DRY principle
● Replicate some functionalities to keep independency
across services
○ No share of business logic

○ Is it the right pattern for your architecture?

● NO, if you still cannot avoid service-component
orchestration
● No definition of transactional unit of work
○ Due to the distributed nature of the pattern
○ Using transaction framework adds too much complexity

Ingegneria del software Riccardo Cardin 25

CONSIDERATIONS
○ Robustness, better scalability, continous delivery
● Small application component, separately deployed
○ Solve many problems of monolithic and SOA architectures

○ Real-time production deployments

● Only changed service components can be deployed
○ Redirection to an error / waiting page
○ Continous availability (hotdeploy)

○ Distributed architeture problems

● Contract creation and maintanance, remote system
availability, remote access authentication, ...
Ingegneria del software Riccardo Cardin 26
PATTERN ANALYSIS
Characteristic Rating Description
Changes are generally isolated. Fast and
Overall agility easy deployment. Loose cooupling
Ease to deploy due to the decoupled
Ease of
nature of service components. Hotdeploy
deployment and continous delivery
Due to isolation of business functions,
Testability testing can be scoped. Small chance of
regression
Due to distributed nature of the pattern,
Performance performance are not generally high
Each service component can be separately
Scalability scaled (fine tuning)
Small and isolated business scope. Less
Ease of
coordination needed among developers or
development development teams

Ingegneria del software Riccardo Cardin 27

PATTERN ANALYSIS
○ Welcome to the jungle…

Ingegneria del software Riccardo Cardin 28

BEYOND THE ARCHITECTURE
“Organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations.”
Melvin Conway

Ingegneria del software Riccardo Cardin 29

RIFERIMENTI
○ Software Architecture Patterns, Mark Richards, 2015, O’Reilly http://
www.oreilly.com/programming/free/software-architecture-
patterns.csp
○ Microservices Patterns, Chris Richardson, 2018, Manning
Publications
https://www.manning.com/books/microservices-patterns

Ingegneria del software Riccardo Cardin 30