Architectures distilled - Kielce JUG, former JDay Lviv Keynote

In 2003 Cambridge's SEI (Software Engineering Institute) tried to put up on their website a definition of architecture. They soon had 90 distinct definitions from books and from the field. The number only grew since then. Why is architecture so difficult to define? Why everybody - and their dog - have their own definition? I'll try distilling architectures, from enterprise frameworks of old (still strong today) to most recent reactive and µservices buzzwords. Showing several approaches, discussing why they were born and where they originate from. In so doing I'll try to offer answers to age-old questions like what is architecture and what do we need it for. Let's synthesize and distill various kinds of architecture, to get to their roots!

Transcript

1. From enterprise to µservices Tomasz Borek, MITORIDAFI &
2. • Infected in childhood • From me parents • Amstrad, ElWro Junior • Games! Doh! • Mem pages in DOS anyone? • In IT • ETL, crawlers, web-app, archi • IAAS, SAAS, own servers • Java 4 – 8, GNU/Linux, SQLs • Ardent “activist” Tomasz Borek
3. A tiny bit infected
4. Can be found on the net! :P
5. Agenda • Finding design flaw • No architects trauma • Architecture for (software) developers • Distilling: – layers, enterprise, – clean, onion, DDD, CCCC… – µservices
8. Cyclomatic complexity • Thomas McCabe • Paths through code • 1 + exits + branches • 10-20 ok • Over 70 bad • Over 90 – almost certainty of a bug – Again: small methods, decrease complexity
9. # changes cc
10. HERE # changes cc
11. 90+ definitions
12. No architects! Ever! • „Were you abused as a child?” •
13. No architects! Ever! • Either „Were you abused as a child?” • Or ...
14. No architects! Ever! • Were you abused as a child? • Brooks, Mythical man-month
15. The glue • Whatever makes your system/solution/program/other work – Business value → Technical constructs – Interactions of components – Requirements (both types) – Infrastructure, network, containers, technology, EULA...
16. The glue • Whatever makes your system/solution/program/other work – Business value → Technical constructs – Interactions of components – Requirements (both types) • My personal fave
18. Siren reuse call
19. Growing software?
20. Layers?
21. Layers • N layers, N == 3 • DAO, logic, presentation
22. Layers • N layers, N == 3 • DAO, logic, presentation – Model – Controller – View
23. Layers • N layers, N == 3 • DAO, logic, presentation – Model – Controller – View – Data Access and Domain → Model, Logic + Control, View/Presentation
24. Layers • N layers, N (usually) == 3 • Client, DB, services?, DAO (some would put model here), logic/domain/(model+)controller, presentation/view – Code grows, so do layers • Technical packages – Public everywhere
26. The formality • Process – Communication – Responsibility – Steps • Architect all the things • Wall of text • Specify all the cases, all the elements – Sometimes with a touch of „system engineer” Software Crisis
27. The formality • Process – Communication – Responsibility – Steps • Architect all the things • Wall of text • Specify all the cases, all the elements – Sometimes with a touch of „system engineer”
28. The formality • Process – Communication – Responsibility – Steps • Architect all the things • Wall of text • Specify all the cases, all the elements – Sometimes with a touch of „system engineer”
29. TDD with FlexUnit, San Jose Flex conf
30. Formality ties closely with HEAVY, strict and regulated documentation
31. Let’s distill the enterprise!
32. Purpose of such formality is: audits, culpability and validation of public spending
36. Clean architecture
40. Onion architecture
42. How to use Onion architecture? CLIENTS use services DIP – Dependency Inversion Principle
43. Domain-driven design Thank you Sławek Sobótka and Bottega folks for some pics
50. Ports and adapters
56. What’s it about?
58. Too perfect to be true
59. • devil’s in the… pipes • Dumb pipes, heavy automation • CFT limits you – Your org does too • Network kills you
61. Books
63. Courtesy of Prophecy of Design Patterns
65. Summarizing And distilling
66. Design flaw • Feathers quadrant • On files: # changes, McCabe’s cyclomatic complexity • Upper right corner
67. No architects • If it’s trauma – see a specialist • Brooks would disagree • Everybody does it? Nobody does • Senior folks • Coding architects, of course
68. Architecture? • Remember the old journal – how many professions were there? • Buildings have layers • The „accidental hole” story • Glue – makes it work, holds it together – Definition(s)?
69. Types of architecture definitions • Glue: connections, elements, interaction • Whatever makes the system meet requirements – Business at heart • Completeness: – Views, perspectives, stakeholders – formal, guarantee, process • Partitioning, dividing the problems – Reuse? Growth? If not required, skip it!
70. Everybody struggles with it
71. Differs per case, per project
72. Differs per case, per project So choose your type each time
73. Distilling architectures from to Tomasz Borek, MITORIDAFI &
74. Enterprise • Law must have it’s way • Architecture description – Documenting the decision! • Stakeholders have different views • It’s not only code – Infrastructure, network, environment, ...
76. Layers • It’s multilayer really – 3-layered is only the most popular • Client is a layer – So is DB • Anemic domain model – Easy to make everything public (tech packages)
77. OOP architectures • Clean – divide layers with objects, don’t cross-cut – Independence is crucial (of frameworks, libs, DBs...) • Onion – DIP, clients, layered • DDD • CCCC
78. OOP architectures • Clean – divide layers with objects, don’t cross-cut, independence is crucial • Onion - DIP, clients, layered • DDD – ubiquitous language, concepts are key, strategic and tactical patterns, map your software • CCCC
80. OOP architectures • Clean – divide layers with objects, don’t cross-cut, independence is crucial • Onion - DIP, clients, layered • DDD – ubiquitous language, concepts are key, strategic and tactical patterns, map your software • CCCC – CONTEXT is king, within it you have CONTAINERS, where COMPONENTS aggregate CLASSES
82. Monolithic architectures • Clean – layered, separation of concerns, DPs • Onion – layered, separation of concerns via services • DDD – consolidates views, layered, strategic and tactical DPs, separation of concerns (multiple building blocks), • CCCC – VIEWS per stakeholder, actually, simple • Could be adapted!
83. Too perfect to be true
84. Microservices • Devil in the details: connections, network, infra – How to connect, scale, discover, monitor, trace… • Devops, platform, network, automation • Cloud requires emphasis on communication • CFT, Conway’s Law
87. Simplify this dammit!! • Architecture must do requirements (glue, makes it work) • Choose yours appropriately AND FRIGGIN DOCUMENT IT – Layers? Separation of concerns? -ilities? Crucial domain? Cloud? Your company’s organization (Conway’s law)? Skills people have? • Simple first step to be better: – Learn about YOURS first and apply the tenets well • Forget reuse and technical packages, remember growth
88. From enterprise to µservices Tomasz Borek, MITORIDAFI & Questions? q→ q+1, 0 < q<=20, q<=0 </ Feedback is welcome!