Application Architectures, Design Patterns
Application Architectures, Design PatternsMartin Ledvinkamartin.ledvinka@fel.cvut.czWinter Term 2017Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20171 / 42
Contents1Software Architecture2Architectural StylesLayered Architecture3Design PatternsGoF Design PatternsEnterprise Design PatternsOther Useful Patterns4Spring Web Application Architecture5ConclusionsMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20172 / 42
Some buzzwords and acronyms for todaySoftware architectureDesign patternSeparation of concernsSingle responsibility principleKeep it simple, stupid (KISS)Don’t repeat yourself (DRY)Don’t talk to strangers(Demeter’s law)Inversion of Control (IoC)Dependency injection (DI)Data Access Object (DAO)Model View Controller (MVC)Hollywood principleEncapsulationHigh cohesion, loose couplingMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20173 / 42
Software ArchitectureSoftware ArchitectureMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20174 / 42
Software ArchitectureWhat is a software architecture?The software architecture of a program or computing system isthe structure or structures of the system, which comprisesoftware elements, the externally visible properties of thoseelements, and the relationships among them. Architecture isconcerned with the public side of interfaces; private details ofelements—details having to do solely with internalimplementation– are not architectural.Bass, Clements, and Kazman Software Architecture in Practice (2ndedition)Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20175 / 42
Software ArchitectureSoftware architectureArchitecture describes the overall structure of a software system. Goodarchitecture enables smooth evolution of the system.It must take into account things likeDeployment environment,Platform and technology specifics,Expected system scope.ArchitectureChanges slowlyInfluences the whole systemArchitectural stylesComponent designRapid change through refactoringSpecific for the componentDesign patternsMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20176 / 42
Software ArchitectureArchitecture design principlesStandard design principles also apply to system-wide architecture, i.e.Separation of concerns,Single responsibility principle,Law of Demeter,Don’t repeat yourself.Before you design the system architecture, you need toDetermine application type,Determine deployment strategy and environment,Determine technologies to use,Determine quality attributes,Determine crosscutting concerns.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20177 / 42
Software ArchitectureArchitecture exampleFigure : System architecture example. 658124.aspxMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20178 / 42
Software ArchitectureSystem architectureUsually consists of multiple architectural styles,Should be well understood by the team,Should be documented (diagrams, pictures, notes),Should clearly expose system structure, while hiding implementationdetails,E.g. show where stuff happens, but not how,Address all user scenarios (eventually),Should handle both functional and non-functional requirements,Evolves as the software grows.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 20179 / 42
Architectural StylesArchitectural StylesMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201710 / 42
Architectural StylesArchitectural stylesThere exist plenty of architectural styles,They are usually combined in an application,Different styles are suitable for different scenarios,Various ways of architectural style classification.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201711 / 42
Architectural StylesArchitectural styles - CommunicationService-Oriented ArchitectureDistributed applications provide services for each other,Using standard protocols and data formats (REST – HTTP andJSON/XML),Loose coupling, easy implementation switch,Microservices.Figure : SOA system example.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201712 / 42
Architectural StylesArchitectural styles - Communication IIMessage BusCentral message queue handles message distribution,Asynchronous messages between clients,Loose coupling, scalability,Enterprise Service Bus – provided by Oracle, IBM etc.Figure : ESB architecture. Source: https://docs.oracle.com/cd/E23943 01/doc.1111/e15020/img/esb architecture.gifMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201713 / 42
Architectural StylesArchitectural styles - DeploymentClient/ServerClient sends requests, server responds,Web applications use this pattern,Server – possible single point of failure and scalability issue.N(3)-tierIndependent tiers providing functionality,Easier scaling,E.g. load balancing, company firewall.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201714 / 42
Architectural StylesArchitectural styles - DomainDomain-driven DesignBusiness components represent domain entities,Suitable for modelling complex domains,Common language and model for developers and domain experts.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201715 / 42
Architectural StylesArchitectural styles - StructureObject-orientedObjects consist of both behaviour and data,Natural representation of real world,Encapsulation of the implementation details.LayeredMore on layers later.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201716 / 42
Architectural StylesArchitectural styles - Structure IIComponent-basedSystem decomposed into logical or functional components,Components provide public interfaces,Supports separation of concerns and encapsulation,Components can be managed by architecture provider,Dependency injection and Service locator used to manageddependencies,Components can be distributed,Higher level than OOP.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201717 / 42
Architectural StylesLayered ArchitectureLayered architectureLayers of related functionality,Typical for web applications,Behaviour encapsulation, clearseparation of concerns, highcohesion, loose coupling,Testability.Figure : Layered systemarchitecture.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201718 / 42
Architectural StylesLayered ArchitectureLayered architecture IIIn contrast to N-tier architecture, the layers are usually in one process(e.g. application server),Each component communicates only with other components withinthe same layer or in the layer(s) below it,Strict interaction Layer communicates only with the layer directlybelow,Loose interaction Layer can communicate also with layers deeperbelow,Crosscutting concerns stem across all layers (e.g. security, logging).Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201719 / 42
Design PatternsDesign PatternsMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201720 / 42
Design PatternsDesign patternsDesign patterns represent generally applicable solutions to commonlyoccurring problems.Patterns mostly consist of (this was cemented by the GoF):Pattern name Simple identification useful in communication,Problem Description of the problem and its context,Solution Solution of the problem (good practice),Consequences Possible trade-offs of applying the pattern.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201721 / 42
Design PatternsGoF Design PatternsGang of Four PatternsBased on the book Design Patterns: Elements of ReusableObject-Oriented Software.Bible of design patterns,Patterns applicable to all kinds of object-oriented software.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201722 / 42
Design PatternsGoF Design PatternsCreational PatternsAbstract Factory Interface for creating families of related objects,Builder Instance construction process in a separate object,Factory Method Subclasses decide which class to instantiate,Prototype Build instances based on a prototype,Singleton Only one instance of the class.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201723 / 42
Design PatternsGoF Design PatternsStructural PatternsAdapter Convert interface of one class to a different interface usingan adapter (e.g. for legacy classes),Bridge Decouple abstraction from implementation,Composite Build tree-like structure of objects,Decorator Add or alter behaviour of another object by wrapping it in aclass with the same interface (e.g. Java I/O streams),Facade Provide a unified interface to a set of interfaces,Flyweight Use sharing to support a large number of fine-grainedobjects,Proxy Provide a placeholder for another object to control access toit (e.g. Spring bean proxies).Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201724 / 42
Design PatternsGoF Design PatternsDecoratorDecorator in Java I/OBufferedReader in new BufferedReader(new FileReader(newFile("input.txt")));Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201725 / 42
Design PatternsGoF Design PatternsBehavioral PatternsChain of Responsibility Multiple objects in a chain can handle a request(e.g. request filters),Command Encapsulate a request in an object (e.g. undo functionality),Interpreter Interpreter for a language and its grammar,Iterator Provide a way to access elements of an aggregate object(e.g. Java collections),Iterator String it set.iterator();Mediator An object that encapsulates how a set of objects interact,Memento Capture object’s state so that it can be restored to this statelater,Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201726 / 42
Design PatternsGoF Design PatternsBehavioral Patterns IIObserver Decoupled notification of changes of object’s state,State Allows object’s behaviour to change based on its internalstate,Strategy A family of algorithms, which can be interchangedindependently of the client,Template method Define a skeleton of an algorithm and let subclasses fillin the details,Visitor Represent an operation to be performed on the elements ofan object structure.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201727 / 42
Design PatternsEnterprise Design PatternsEnterprise Design PatternsMostly based on the book Patterns of Enterprise Application Architecture.Design patterns used especially in enterprise software,Similarly to GoF design patterns, they originate from best practicesolutions to common problems, but this time in enterprise applicationdevelopment.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201728 / 42
Design PatternsEnterprise Design PatternsPEAAData Transfer Object (DTO)Object that carries data between processes in order to reduce thenumber of calls,Useful e.g. when JPA entities are not the best way of carrying databetween REST interfaces.Lazy LoadObject does not contain all of its data initially, but knows how to loadit,Useful for objects holding large amounts of data (e.g. binary data),Often overused as a way of premature optimization.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201729 / 42
Design PatternsEnterprise Design PatternsPEAA IIModel View Controller (MVC)Splits user interface interaction into three distinct roles,Decouples UI rendering from data and UI logic,UI implementation interchangeable.Unit Of WorkMaintains objects affected by a business transaction and coordinatesthe writing out of changes and the resolution of concurrency problems,Common in JPA implementations (e.g. Eclipselink).Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201730 / 42
Design PatternsOther Useful PatternsData Access Object (DAO)Data access object encapsulates all access to the data source,Abstract interface hides all the details of data source access (datasource can be a RDBMS, an external service, a linked datarepository).Figure : Common Data access object hierarchy.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201731 / 42
Design PatternsOther Useful PatternsInversion of Control (IoC)Most common when working with frameworks,The framework takes control of what and when gets instantiated andcalled,The framework embodies some abstract design and we providebehaviour in various places,Especially important in applications which react to some client’sactions,Be it a different application,or a client using your application’s UI,aka The Hollywood Principle – “Don’t call us. We’ll call you.”Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201732 / 42
Design PatternsOther Useful PatternsIoC IIFigure : Inversion of Control in a Spring application.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201733 / 42
Design PatternsOther Useful PatternsDependency InjectionAn assembler takes care of populating a field in a class with anappropriate implementation for the target interface,Enables the application to use loosely coupled components withinterchangeable implementations.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201734 / 42
Design PatternsOther Useful PatternsDependency Injection IIFigure : Dependency injection principle.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201735 / 42
Spring Web Application ArchitectureSpring Web ApplicationArchitectureMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201736 / 42
Spring Web Application ArchitectureSpring web application architectureTypically layered,Usually three layers,Relies on DI and IoC provided by the Spring container,Various possibilites for the top and bottom layers:Spring MVC, REST services, SOAP services for the web layer,Spring JPA, Spring JDBC,Integrated support for security.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201737 / 42
Spring Web Application ArchitectureSpring application layersFigure : Spring web application architecture. /uploads/spring-web-application-layers.pngMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201738 / 42
ConclusionsConclusionsMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201739 / 42
ConclusionsConclusionsApplication design does matter,Architecture consists of multiple architectural styles,Design patterns are more fine grained than architectural styles,Web applications usually follow the layered style.Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201740 / 42
ConclusionsThe EndThank YouMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201741 / 42
ConclusionsResourcesM. Fowler: Patterns of Enterprise Application Architecture,E. Gamma, R. Johnson, R. Helm, J. Vlissides: Design Patterns:Elements of Reusable Object-Oriented Software,E. Evans: Domain Driven Design: Tackling Complexity in the Heartof Software,Lectures of Tomáš Černý – plication-architecture-the-classicMartin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design PatternsWinter Term 201742 / 42
Contents 1 Software Architecture 2 Architectural Styles Layered Architecture 3 Design Patterns GoF Design Patterns Enterprise Design Patterns Other Useful Patterns 4 Spring Web Application Architecture 5 Conclusions Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application
Microservice-based architectures. Using containerisation in hybrid cloud architectures: Docker, Kubernetes, OpenShift: Designing microservice architectures. Managing microservice architectures. Continuous integration and continuous delivery (CI/CD) in containerised architectures. Cloud-native microservice architectures: serverless.
LLinear Patterns: Representing Linear Functionsinear Patterns: Representing Linear Functions 1. What patterns do you see in this train? Describe as What patterns do you see in this train? Describe as mmany patterns as you can find.any patterns as you can find. 1. Use these patterns to create the next two figures in Use these patterns to .
1. Transport messages Channel Patterns 3. Route the message to Routing Patterns 2. Design messages Message Patterns the proper destination 4. Transform the message Transformation Patterns to the required format 5. Produce and consume Endpoint Patterns Application messages 6. Manage and Test the St Management Patterns System
141 Design Patterns Are Not About Design Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Design patterns are not complex, domain-specific designs for an entire application or subsystem. Design patterns are descriptions of communicating objects and classes that are customized to solve a general design
Creational patterns This design patterns is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns
There are different types and levels of design patterns. For example, the MVC is the architectural level of design pattern while the rest of the patterns from the list above are component level design patterns. The basic types are Behavior, Creational, Structural, and System design patterns. Names are extremely important in design .
Distributed Systems Stream Groups Local Patterns Global Patterns Figure 1: Distributed data mining architecture. local patterns (details in section 5). 3) From the global patterns, each autonomous system further refines/verifies their local patterns. There are two main options on where the global patterns are computed. First, all local patterns
An API (US) nationally adopted standard, either modified from or identical to the ISO standard, may include the API Monogram Program requirements. This shall be noted on the front cover as to be evident to the reader. Both modified and identical adoptions which include the API Monogram should be designated as follows: API Title . ANSI/API XX . Edition, Month/Year . Effective Date: (minimum of .
