Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architectures distilled - Kielce JUG, former JDay Lviv Keynote

Tomasz Borek
November 26, 2018

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!

Tomasz Borek

November 26, 2018
Tweet

More Decks by Tomasz Borek

Other Decks in Science

Transcript

  1. • 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
  2. Agenda • Finding design flaw • No architects trauma •

    Architecture for (software) developers • Distilling: – layers, enterprise, – clean, onion, DDD, CCCC… – µservices
  3. 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
  4. 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...
  5. The glue • Whatever makes your system/solution/program/other work – Business

    value → Technical constructs – Interactions of components – Requirements (both types) • My personal fave
  6. Layers • N layers, N == 3 • DAO, logic,

    presentation – Model – Controller – View
  7. Layers • N layers, N == 3 • DAO, logic,

    presentation – Model – Controller – View – Data Access and Domain → Model, Logic + Control, View/Presentation
  8. 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
  9. 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
  10. 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”
  11. 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”
  12. • devil’s in the… pipes • Dumb pipes, heavy automation

    • CFT limits you – Your org does too • Network kills you
  13. Design flaw • Feathers quadrant • On files: # changes,

    McCabe’s cyclomatic complexity • Upper right corner
  14. No architects • If it’s trauma – see a specialist

    • Brooks would disagree • Everybody does it? Nobody does • Senior folks • Coding architects, of course
  15. 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)?
  16. 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!
  17. Enterprise • Law must have it’s way • Architecture description

    – Documenting the decision! • Stakeholders have different views • It’s not only code – Infrastructure, network, environment, ...
  18. 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)
  19. OOP architectures • Clean – divide layers with objects, don’t

    cross-cut – Independence is crucial (of frameworks, libs, DBs...) • Onion – DIP, clients, layered • DDD • CCCC
  20. 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
  21. 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
  22. 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!
  23. 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
  24. 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