An Introduction to Multilayered Software Architecture

An introduction to Multilayered Software Architecture

1 april 2016Andrei Pîrjoleanu

2

› What is “Multilayered Architecture”?

› Advantages/Disadvantages

› What layers?

› Implementation

› Further directions

› Conclusions

Agenda

3

› “A multilayered software architecture is a software architecture that uses many layers for allocating the different responsibilities of a software product”

https://en.wikipedia.org/wiki/Multilayered_architecture

What is “Multilayered Architecture”?Definition

4

› “In object-oriented design, a layer is a group of classes that have the same set of link-time module dependencies to other modules. In other words, a layer is a group of reusable components that are reusable in similar circumstances”

› “Layers are often arranged in a tree-form hierarchy, with dependency relationships as links between the layers.”

https://en.wikipedia.org/wiki/Layer_(object-oriented_design)

What is “Multilayered Architecture”?The “Layers” architectural pattern

5

› Spaghetti code:

Complex and tangled control structure

“unstructured” branching constructs

Can be caused by several factors, such as continuous modifications by several people over a long life cycle

https://en.wikipedia.org/wiki/Spaghetti_code

› Lasagna code:

characterized by several well-defined and separable layers, where each layer of code accesses services in the layers below through well-defined interfaces

Enforces encapsulation between the different layers

https://en.wikipedia.org/wiki/Spaghetti_code#Lasagna_code

What is “Multilayered Architecture”?Spaghetti vs Lasagna

6

Increased flexibility, maintainability and scalability

Multiple applications can reuse the components

Enables teams to work on different parts of the application in parallel with minimal dependencies on other teams

Different components can be independently deployed, maintained and updated, on different time schedules

It allows you to test the components independently of each other

Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.

Allows replacement of entire layers so long as the interface is maintained.

Advantages vs DisadvantagesAdvantages

7

It helps to control and encapsulate the complexity of large applications, but adds complexity to simple applications

More difficult to set up and maintain as well

In practice, a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it

Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer

Advantages vs DisadvantagesDisadvantages

8

Infrastructure

Presentation

Application

Domain

Persistence

What layers?Common layers

Presentation

Application

Domain

PersistenceInfr

astr

uctu

re

9

What layers?Common layers

Infrastructure

Presentation

Application

Domain

Persistence

10

› Also known as: UI layer, view layer

› It determines how the data will be presented

› It uses a data-validation strategy to protect the system from untrusted input

› Does not contain any business logic

What layers?Presentation layer

11

› Also known as: Application Service layer, Services layer

› It represents the use cases and behavior of the application

› Operates at a higher level of abstraction than the Domain layer (exposes what the system does, but not how it does it)

› It requires dependencies on external layers

› It contains only application logic (security, transaction management, communication), being all about coordination and orchestration through delegation to Domain and Infrastructural services

› Can sometimes be found implemented as a part of the Domain layer

› Does not contain any business logic

What layers?Application layer

12

› Also known as: Business layer, Business logic layer (BLL)

› Represents a conceptual abstract view of the problem domain created to fulfill the needs of the business use cases

› Prescribes how business objects interact with one another

› Focused only on Domain rules, concepts, information and workflows

› Does not depend on anything else

› Does not contain any technical details, nor persistence details

What layers?Domain layer

13

› Also known as: Data access layer (DAL)

› Provides simplified access to data stored in persistent storage of some kind, such as an entity-relational database

› Hides the complexity of the underlying data store from the external world

› Provides a centralized location for all calls into the storage and thus makes it easier to port the application to other database systems

› Most implemented layers will not achieve persistence directly, but will use a storage engine located in the Infrastructure layer

› Can sometimes be found implemented as a part of the Infrastructure layer

› Does not contain any business logic

What layers?Persistence layer

14

› It gives energy to a system; you will not be able to run the application without it

› Contains technical details that enable the application to function

› Is concerned with purely technical capabilities, such as messaging, logging, security, notifications, operations, commands, events, integration services, storage engines etc.

› Should not directly affect the use case exposed and the Domain logic of an application

› Can be partitioned into different levels (high-level or low-level technical services)

› Does not contain any business logic

What layers?Infrastructure layer

15

› Some also identify a separate layer called the Business Infrastructure layer (BI), located between the Domain layer and the Infrastructure layer; this layer is very general and can be used in several application tiers (e.g. a CurrencyConverter)

› All types are not always exclusive to one particular layer; a relaxed layered system (as opposed to a strict layered system) can use so called “shared data definition modules”, which are types not belonging in a particular layer

What layers?Other notes

16

Implementation4 layer architecture

ComponentsApplication

services

Domain Services

Controllers UI views

Domain Entities

Value Objects

Repository Contracts

Unit of Work Repositories Gateways Query handlers

Commands

Storage adapters Storage adapters

Inte

grat

ion

serv

ices

3rd

Part

y Ad

apte

rs

Erro

r Hu

bCo

mm

and

Bus

Cach

eSe

curit

y

17

Implementation“Check Item stock” use case – Distributing responsibility

ItemController

WarehouseManagerService

ProductModel StockModel

ProductRepository StockRepository

ProductMysqlGateway StockMySqlGateway

ErrorHub

MessageBus

NotificationBus

MySqlStorageAdapter MongoDbSTorageAdapter

StockMongoDBGateway

18

Implementation“Check Item stock” use case – Flow

ItemController WarehouseManagerService ProductMySqlGateway

MySqlStorageAdapter

StockRepository StockGateway

ProductRepository

checkStock getProductByCode getProductByCode

getRow

return rowreturn ProductDTOreturn ProductModel

getStockByItem getStockByItem

getRow

return rowreturn StockDTOreturn StockModelreturn StockDTO

19

ImplementationDependency inversion

20

ImplementationDependency inversion principle (SOLID)

› It refers to a specific form of decoupling software modules

A. High-level modules should not depend on low-level modules. Both should depend on abstractions

B. Abstractions should not depend on details. Details should depend on abstractions.

› The goal is to avoid the highly coupled distribution with the mediation of an abstract layer, and to increase the re-usability of higher/policy layers

21

ImplementationDependency inversion

22

ImplementationHexagonal architecture

23

ImplementationOnion architecture

24

ImplementationReusable patterns

› Value Objects

› Entities

› Aggregates

› Domain Services

› Domain Events

› Factories

› Repositories

› Gateways

› Data Mappers

› Data Transfer Objects (DTOs)

› Query Object

› Identity Map

› Unit of Work

25

Further directionsBounded Contexts

26

27

Further directionsOther concepts

› DDD Domain-Driven Design

or how to effectively manage the construction and maintenance of software for complex problem domains

› Commands, Command Handlers, Command Bus

› Events, Event Listeners, Event Dispatcher

› CQRS Command Query Responsibility Segregation

or how to separate Read and Write

28

Conclusions

› Single responsibility

› Dependency inversion

› Separation of concerns

› Ports/Adapters – a.k.a. Interfaces and Concrete implementations

› Reusable patterns

29

References

› https://en.wikipedia.org/wiki/Multilayered_architecture

› http://csis.pace.edu/~marchese/CS389/L6/Chapter%206_Summary.pdf

› http://alistair.cockburn.us/Hexagonal+architecture

› http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

› “Patterns, Principles and Practices of Domain-Driven Design” – Scott Millett with Nick Tune

› “Patterns of Enterprise Application Architecture” – Martin Fowler

Avangate

Redwood Shores, California - USAAmsterdam - NetherlandsBucharest – RomaniaAtlanta, Georgia - USA

Tel: (650) 249 – 5280 / +31 20 890 8080

Q&A