Downloaded 27 times
An Introduction to Multilayered Software Architecture
- 1. An introduction toMultilayered 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 multilayeredsoftware 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-orienteddesign, 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 helpsto 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.
- 10. 10 › Also knownas: 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 knownas: 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 knownas: 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 knownas: 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 givesenergy 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 alsoidentify 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 ControllersUI 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.
- 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.
- 22.
- 23.
- 24. 24 Implementation Reusable patterns › ValueObjects › Entities › Aggregates › Domain Services › Domain Events › Factories › Repositories › Gateways › Data Mappers › Data Transfer Objects (DTOs) › Query Object › Identity Map › Unit of Work
- 25.
- 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