Download to read offline
App Design Architecture
- 1. Architektura a jejínávrh Spring framework training materials by Roman Pichlík is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Sunday 26 May 13
- 2.
- 3. Sunday 26 May13 Sagrada Familia (Barcelona), Chrám Sv. Víta v Praze
- 4. “Applications architecture isthe science and art of ensuring the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available and manageable” http://en.wikipedia.org/wiki/Applications_architecture Sunday 26 May 13 Věda a umění stejně jako v případě architektonických skvostů ve stavitelství
- 5. Architektura a jejízákladní charakteristika Sunday 26 May 13 zájmy = uživatelé, vlastníci, operations co a jak= integrita, vize je oddělená od vlastní implementace => umožňuje další evoluci
- 6. Respektuje zájmy všech Architektura ajejí základní charakteristika Sunday 26 May 13 zájmy = uživatelé, vlastníci, operations co a jak= integrita, vize je oddělená od vlastní implementace => umožňuje další evoluci
- 7. Respektuje zájmy všech Oddělení odpovědností Architektura ajejí základní charakteristika Sunday 26 May 13 zájmy = uživatelé, vlastníci, operations co a jak= integrita, vize je oddělená od vlastní implementace => umožňuje další evoluci
- 8. Respektuje zájmy všech Oddělení odpovědností Odděluje Co aJak Architektura a její základní charakteristika Sunday 26 May 13 zájmy = uživatelé, vlastníci, operations co a jak= integrita, vize je oddělená od vlastní implementace => umožňuje další evoluci
- 9. Respektuje zájmy všech Oddělení odpovědností Řízená kvalitou Odděluje Coa Jak Architektura a její základní charakteristika Sunday 26 May 13 zájmy = uživatelé, vlastníci, operations co a jak= integrita, vize je oddělená od vlastní implementace => umožňuje další evoluci
- 10.
- 11. Kvalita Sunday 26 May13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 12. škálovatelnost špatná výkonnost Kvalita Sunday26 May 13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 13. rozšiřitelnost technologický dluh overengineering škálovatelnost špatnávýkonnost Kvalita Sunday 26 May 13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 14. rozšiřitelnost technologický dluh overengineering operovatelnost drahýprovoz škálovatelnost špatná výkonnost Kvalita Sunday 26 May 13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 15. rozšiřitelnost technologický dluh overengineering operovatelnost drahýprovoz škálovatelnost špatná výkonnost Kvalita bezpečnost zranitelnost Sunday 26 May 13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 16. rozšiřitelnost technologický dluh overengineering operovatelnost drahýprovoz škálovatelnost špatná výkonnost Kvalita bezpečnost zranitelnost testovatelnost nepředvidatelnost Sunday 26 May 13 Zaměření na atributy nesouvisející přímo s funkčními požadavky
- 17.
- 18. Motivace • Modulárnost • Kompozicelow-level částí do větších celků • Snížení komplexity • Jednodušší správa • Refactoring • Rozšířitelnost Sunday 26 May 13
- 19. Dva zásadní vzory •Oddělení struktury dat od jejich prezentace • Rozdělení aplikace na vrstvy s různou odpovědností • Třívrstvá architektura Sunday 26 May 13
- 20.
- 21. Sunday 26 May13 Návrhové vzory - mnoho problémů a jejich řešení lze generalizovat - různá úroveň abstrakce (objekty, komponenty, systémy)
- 22. GoF Design patterns •Vzory řešící vznik objektů • Vzory řešící strukturu objektů • Vzory řešící chování objektů Sunday 26 May 13 Řeší problémy na úrovni návrhu objektů a jejich interakce - Factory a Factory method, Builder, Lazy initialization, Object pool, Singleton - Bridge, Composite, Decorator, Facade, Proxy - Template method, Strategz, Null object, Iterator, Command
- 23. • Cvičení • Vyjmenujtealespoň 4 GoF návrhové vzory, které používá vaše aplikace případně knihovny, které používáte Sunday 26 May 13
- 24. J2EE patterns • Vzoryřešící prezentační vrstvu • Vzory pro aplikační logiku • Vzory integrační vrstvy Sunday 26 May 13 Vznikly na základě složitosti Java EE - Composite view, View helper, Front controller, Application controller - Service facade, Transfer object, Business object, Service locator - Data Access Object, Web service broker
- 25. Architektonické vzory • MartinFowler a kol. • Rozdělení vzorů podle vrstev • De facto standard pro popis částí aplikace • Vliv • Webové a ORM frameworky Sunday 26 May 13 Vzory ovlivňovaly celou řadu oblastí ORM - active record, lazy load, identity map, mapování dědičnosti Webové frameworky - front controller, application controller, MVC
- 26. Datová vrstva aplikace DataSource Architectural Patterns Object-Releation vrstva Object-Relational Behavioral Patterns Object-Relational Structural Patterns Object-Relational Metadata Mapping Prezentační vrstva aplikace Aplikační vrstva aplikace Distribution patterns Web presentation patterns Offline concrrency patterns Session state patterns Domain logic patterns Base patterns Sunday 26 May 13
- 27. Datová vrstva Sunday 26May 13 Mnoho těchto vzorů znáte z tradičních frameworků.
- 28. Query object • Objektzapouzdřující databázový dotaz • Interpretr z GoF • Umožňuje různý způsob překladu v závislosti na persistentním úložišti Sunday 26 May 13
- 29. Lazy load • Objekt,který neobsahuje všechny data, ale ví jak je nahrát • Výkonost Sunday 26 May 13
- 30. Identity map • Zajišťujenahrání objektu pouze jednou v rámci business transkace • Výkonnost Sunday 26 May 13
- 31. Unit of Work •Udržuje seznam všech objektů načtených a modifikovaných v rámci business transakce • Zajišťuje správné pořadí DML příkazů • DELETE, INSERT, UPDATE Sunday 26 May 13
- 32. Active Record • Objektzapouzdřuje jeden řádek v databázi • Databázová logika součástí doménového objektu • Usnadňuje práci klientům Sunday 26 May 13
- 33. Single table inheritance •Objektová dědičnost mapovaná do jedné tabulky • Není potřeba join přes více tabulek • select * from Players Sunday 26 May 13
- 34. Concrete table inheritance •Každá třída má vlastní tabulku • Výhodné pokud se objekty liší • Not null sloupce Sunday 26 May 13
- 35. Serialized LOB • Grafobjektů (hierarchie) je sezializován jako celek do (B)LOB struktury • SELECT výkonost • Přicházíme o výhody relační databáze Sunday 26 May 13
- 36.
- 37. Optimistic offline lock •Ochrana před konkurenčním přepisem dat • Umožňuje více klientům pracovat s jednou verzí dat • Kontrola zámku při zápisu Sunday 26 May 13
- 38. Pessimistic offline lock •Ochrana před konkurenčním přepisem dat • Menší propustnost • Jistota, že transakce bude dokončena Sunday 26 May 13
- 39. Coarse-grained lock • Zámekasociovaný se skupinou objektů • Jednodušší zamykání • Výkonnost • Není potřeba nahrávat každý jednotlivý objekt Sunday 26 May 13
- 40. Service stub • Odstraněnítěsné vazby na problematické části systému během vývoje • In-memory stub • Cíl • rychlost vývoje Sunday 26 May 13
- 41. Gateway • Objekt (rozhraní) zapouzdřující přístupdo externího systému • Změna technologie Sunday 26 May 13
- 42. Domain model • Model,který zapouzdřuje data a jejich vazby pro danou doménu Sunday 26 May 13
- 43. Service layer • Zapouzdřujeaplikační logiku pro vyšší vrstvy aplikace • Usnadňuje interakci • Koordinace transakcí Sunday 26 May 13
- 44.
- 45. Model View Controller •Oddělení odpovědností při obsluze uživatelského rozhraní • Umožňuje zvolit různou prezentaci • Testovatelnost Sunday 26 May 13
- 46. Front controller • Obsluhaspolečných vlastností pro celou webovou aplikaci • Internacionalizace • Překlad výjimek • Snižuje komplexitu aplikačních controlleru Sunday 26 May 13
- 47. Application controller • Zapouzdřuje navigacipro složitější flow • Wizards Sunday 26 May 13
- 48. Remote facade • Poskytujecoarse- grained interface pro vzdálené volání • Větší efektivita • Menší počet síťových volání Sunday 26 May 13
- 49. Data Transfer Objects •Přepravka pro data • Minimalizuje počet vzdálených volání Sunday 26 May 13
- 50. • Cvičení • Vyjmenujtealespoň 4 architektonické vzory, které používá vaše aplikace • Vyjmenujte 4 Architektonické vzory, které používají knihovny ve vaší aplikaci Sunday 26 May 13
- 51.
- 52. • Anémický doménovýmodel • Leaky abstraction • Prosakující API z nižších vrstev • Overenginering Sunday 26 May 13 Proč zavádíme abstrakci? Zjednodušení. Komplexní abstrakce leakuje ve složitejších případech - jsme nuceni pochopit jak to funguje pod kapotou např. ORM, SQL atd.
- 53. Škálovatelnost a výkonost Sunday26 May 13
- 54. Škálovatelnost Škálovatelnost je schopnostsystému zvýšit výkonnost proporčně k přidaným zdrojům. Zvýšení výkonnosti znamená obsluhu více požadavků a nebo požadavků větší velikosti. -- Werner Vogels CTO - Amazon.com http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html Sunday 26 May 13
- 55. Horizontální škálovatelnost • Scale-out •Přidání nových výpočetních uzlů • Cluster • Přináší sebou jinou rodinu problémů v distribuovaném prostředí Sunday 26 May 13
- 56. Vertikální škálovatelnost • Přidáníprostředků existujícímu systému • CPU, RAM, Disk • Hardwarové limity • Cena Sunday 26 May 13
- 57. Load balancing Sunday 26May 13
- 58. Rozložení zátěže • Roundrobin • Sticky session (Affinity) Sunday 26 May 13
- 59. Dva módy • Centrálníload balancer • Klientský load balancer Sunday 26 May 13
- 60. Škálování databáze • Slavereads • Sharding • CAP theorem Sunday 26 May 13
- 61. • Workshop návrhrezervačního systému ubytování (booking.com) • Systém má tyto základní části • Billing, User/Hotel management, Booking, Frontend • Billing je zajišťován externím systémem • Login do systému je možný i přes OpenId (Facebook) • Aplikace je webová a musí umožnit přístup z mobilních zařízení • Očekává se integrace s dalšími systémy • Navrhněte základní architekturu systému • Komponenty/Služby a jejich vrstvy • Jakým způsobem zajistíte škálovatelnost • Kde očekáváte bottleneck • Jaké technologie a proč je použijete Sunday 26 May 13