JSLab. Георгий Подсветов "Путь архитектора. Введение в архитектурные паттерны."
•
1 like•444 views
28.03.15. Одесса. Impact Hub Odessa. Конференция JSLab. Георгий Подсветов "Путь архитектора. Введение в архитектурные паттерны." В рамках данного доклада мы познакомимся с рядом архитектурных паттернов, поговорим об их назначениях, сильных и слабых сторонах. Обсудим возможность создания гибридных решений. Поговорим о том, почему важно знать и понимать архитектурные паттерны. И конечно же вы получите рекомендации по дальнейшему развитию этого направления. Подробнее: http://geekslab.co/ https://www.facebook.com/GeeksLab.co https://www.youtube.com/user/GeeksLabVideo
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Similar to JSLab. Георгий Подсветов "Путь архитектора. Введение в архитектурные паттерны."
Similar to JSLab. Георгий Подсветов "Путь архитектора. Введение в архитектурные паттерны." (20)
More from GeeksLab Odessa
More from GeeksLab Odessa (20)
Recently uploaded
Recently uploaded (20)
JSLab. Георгий Подсветов "Путь архитектора. Введение в архитектурные паттерны."
- 1. Introduc)on to architectural pa1erns Georgiy Podsvetov podsvetov@gmail.com
- 2. Layered architecture Presenta)on layer Business layer Persistence layer Database layer 2
- 3. Layered architecture closed • Presenta)on layer closed • Business layer closed • Persistence layer Closed • Database layer • Layers communicate from top to down only • To get layer below, you have to go through all in the middle 3
- 4. What if we have some kind of shared services? closed • Presenta)on layer closed • Business layer closed • Services layer closed • Persistence layer Closed • Database layer Do we s)ll need pass all request throw this layer? 4
- 5. Open layered architecture closed • Presenta)on layer closed • Business layer open • Services layer closed • Persistence layer Closed • Database layer Some layers might be open. 5
- 6. Layered architecture • Good general purpose architecture • Easy to implement, test, and govern • Good star)ng point for most systems • Not always op)mized for specific business drivers closed • Presenta)on layer closed • Business layer closed • Services layer closed • Persistence layer Closed • Database layer closed • Presenta)on layer closed • Business layer open • Services layer closed • Persistence layer Closed • Database layer 6
- 7. Event-‐driven architecture • Event processor topology • Broker topology • Broker-‐less topology 7
- 8. Event processor topology Event queue Event processor Event topic Event topic processor processor processor processor processor Event orchestra)on 8
- 9. Broker topology Event topic Event topic processor processor processor processor processor Event topic Event processor processor processor media)on 9
- 10. Event process process process Broker-‐less topology Event process process process 10
- 11. Event-‐driven architecture • Highly decoupled and distributed • Highly scalable • High degree of complexity • Good for event-‐based business models and business processes • Not good for processes which require a high degree of data sharing, orchestra)on, and reuse 11
- 12. Service-‐oriented architecture Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator 12
- 13. Business services Abstract service used to represent a business process or func)on independent of the underlying technology or pa1ern • Сan be derived from use cases, user stories, user scenarios • Contains a service name, input specifica)on, and output specifica)on • Course-‐grained • Shared across the enterprise Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator 13
- 14. Enterprise services Concrete services that implement Business Services Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator • The rela)onship between an Enterprise Service and a Business Service is either a one-‐to-‐one or many-‐to-‐one rela)onship • Course-‐grained • Represent ac)ons against major data en))es • Usually require some sort of service orchestra)on • Shared across the enterprise 14
- 15. Applica)on services Implementa)on of applica)on-‐specific func)ons, such as database querying, valida)on, etc. Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator • Concrete defini)on • Defined by applica)on developers • Fine-‐grained • Tightly bound to a specific applica)on context • Generally not shared across the enterprise 15
- 16. Infrastructure services Implementa)on of the non-‐business related func)ons, like logging, error handling, single sign on, etc. Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator • Concrete defini)on • Defined by applica)on or system developers • Fine-‐grained • Supports the system or enterprise infrastructure • Shared across the enterprise 16
- 17. Message Bus Coordinates services and processes, it’s a glue for SOA components Business services Enterprise services Applica)on services Infrastructure services Message bus BS BS BS BS BS ES ES ES ES ES AS IS Process choreographer Service orchestrator • Process choreography • Service orchestra)on • Service registry • Protocol transforma)on • Message enhancement and transforma)on 17
- 18. Service-‐oriented architecture • Good pa1ern for understanding and implemen)ng business processes and services • Very high level of complexity • Difficult to implement due to complex tools, hype, misconcep)ons, and heavy business user involvement • Good pa1ern for large, complex, heterogeneous businesses that have a large number of common services 18
- 19. Pipeline architecture Producer Transformer Transformer Tester Consumer pipe pipe pipe pipe 19
- 20. Pipes and filters • Uni-‐direc)onal only • Usually point-‐to-‐point for high performance, but could be message-‐based for scalability • Payload can be any type pipe filter • Self-‐contained and independent from other filters • Usually designed to perform a single specific task 20
- 21. Filter types Producer Tester Consumer pipe pipe Transformer pipe pipe pipe pipe Star)ng point, outbound only Input, processing, output Input, discard or pass-‐thru Endpoint, inbound only 21
- 22. Pipeline architecture • Useful for smaller determinis)c systems with a dis)nct processing flow • Filters can easily be added and removed • Provides for a high level of decoupling • Supports evolu)onary design • Able to easily adapt to changing requirements • Can be easily incorporated into another pa1ern Producer Transformer Transformer Tester Consumer pipe pipe pipe pipe 22
- 23. Microkernel architecture Core Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module 23
- 24. Microkernel architecture • Minimal func)onality to run system • General business rules and logic • Doesn’t contain custom processing Core Plug-‐in module • Standalone independent module • Specific addi)onal rules or logic Core Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module 24
- 25. Microkernel architecture • Useful for systems that have custom processing or processing is suscep)ble to change • Plug-‐in modules can be easily added and removed • Supports evolu)onary design • Able to easily adapt to changing requirements • Can easily be incorporated into another pa1ern Core Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module Plug-‐in module 25
- 26. Space-‐based architecture Virtualized middleware Messaging grid Data grid Processing grid Deployment manager Processing unit -‐ -‐ -‐ -‐ -‐ -‐ -‐ Processing unit -‐ -‐ -‐ -‐ -‐ -‐ -‐ Processing unit -‐ -‐ -‐ -‐ -‐ -‐ -‐ 26
- 27. Processing unit Module Module Module DB In-‐memory data Data replica)on engine In fact it is standalone version of yours applica)on 27
- 28. Virtualized middleware Manages input request and session Messaging grid Data grid Processing grid Deployment manager Manages data replica)on between processing units Manages parallel request processing Manages dynamic processing unit deployment 28
- 29. Space-‐based architecture • Good for applica)ons that have variable load or inconsistent peak )mes • Not good fit for tradi)onal large-‐scale rela)onal database systems • Rela)vely complex and expensive pa1ern to implement Virtualized middleware Messaging grid Data grid Processing grid Deployment manager Processing unit -‐ -‐ -‐ -‐ -‐ Processing unit -‐ -‐ -‐ -‐ Processing unit -‐ -‐ -‐ -‐ -‐ 29
- 30. h1p://goo.gl/BiV940 h1p://goo.gl/vmv0Ww h1p://goo.gl/NI6uE2 h1p://goo.gl/XEw0JB Ques)ons? Georgiy Podsvetov podsvetov@gmail.com Recommended reading: h1p://ua.linkedin.com/pub/georgiy-‐podsvetov/45/989/868 h1ps://www.facebook.com/GeorgiyPodsvetov 30 h1p://www.slideshare.net/GeorgiyPodsvetov/jslab2015-‐0328 (h1p://goo.gl/7W2zNs) Slides: