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