1. An introduction to Multilayered
Software Architecture
1 april 2016
Andrei Pîrjoleanu

2. 2
› What is “Multilayered Architecture”?
› Advantages/Disadvantages
› What layers?
› Implementation
› Further directions
› Conclusions
Agenda

3. 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. 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. 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. 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 Disadvantages
Advantages

7. 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 Disadvantages
Disadvantages

8. 8
 Infrastructure
 Presentation
 Application
 Domain
 Persistence
What layers?
Common layers
Presentation
Application
Domain
Persistence
Infrastructure

9. 9
What layers?
Common layers
Infrastructure
Presentation
Application
Domain
Persistence

10. 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. 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. 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. 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. 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. 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. 16
Implementation
4 layer architecture
Components
Application
services
Domain
Services
Controllers UI views
Domain
Entities
Value
Objects
Repository
Contracts
Unit of Work Repositories Gateways
Query
handlers
Commands
Storage adapters Storage adapters
Integration
services
3rdPartyAdapters
Error
Hub
Command
Bus
CacheSecurity

17. 17
Implementation
“Check Item stock” use case – Distributing responsibility
ItemController
WarehouseManagerService
ProductModel StockModel
ProductRepository StockRepository
ProductMysqlGateway StockMySqlGateway
ErrorHub
MessageBus
NotificationBus
MySqlStorageAdapter MongoDbSTorageAdapter
StockMongoDBGateway

18. 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. 19
Implementation
Dependency inversion

20. 20
Implementation
Dependency 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. 21
Implementation
Dependency inversion

22. 22
Implementation
Hexagonal architecture

23. 23
Implementation
Onion architecture

24. 24
Implementation
Reusable 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. 25
Further directions
Bounded Contexts

26. 26

27. 27
Further directions
Other 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. 28
Conclusions
› Single responsibility
› Dependency inversion
› Separation of concerns
› Ports/Adapters – a.k.a. Interfaces and Concrete implementations
› Reusable patterns

29. 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

30. Avangate
Redwood Shores, California - USA
Amsterdam - Netherlands
Bucharest – Romania
Atlanta, Georgia - USA
Tel: (650) 249 – 5280 / +31 20 890 8080
Q&A