$30 off During Our Annual Pro Sale. View Details »

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. From enterprise to
    µservices
    Tomasz Borek, MITORIDAFI
    &

    View Slide

  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

    View Slide

  3. A tiny bit infected

    View Slide

  4. Can be found on the net! :P

    View Slide

  5. Agenda

    Finding design flaw

    No architects trauma

    Architecture for (software) developers

    Distilling:
    – layers, enterprise,
    – clean, onion, DDD, CCCC…
    – µservices

    View Slide

  6. View Slide

  7. View Slide

  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

    View Slide

  9. # changes
    cc

    View Slide

  10. HERE
    # changes
    cc

    View Slide

  11. 90+
    definitions

    View Slide

  12. No architects! Ever!

    „Were you abused as a child?”

    View Slide

  13. No architects! Ever!

    Either „Were you abused as a child?”

    Or ...

    View Slide

  14. No architects! Ever!

    Were you abused as a child?

    Brooks, Mythical man-month

    View Slide

  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...

    View Slide

  16. The glue

    Whatever makes your system/solution/program/other
    work
    – Business value → Technical constructs
    – Interactions of components
    – Requirements (both types)

    My personal fave

    View Slide

  17. View Slide

  18. Siren reuse call

    View Slide

  19. Growing software?

    View Slide

  20. Layers?

    View Slide

  21. Layers

    N layers, N == 3

    DAO, logic, presentation

    View Slide

  22. Layers

    N layers, N == 3

    DAO, logic, presentation
    – Model – Controller – View

    View Slide

  23. Layers

    N layers, N == 3

    DAO, logic, presentation
    – Model – Controller – View
    – Data Access and Domain → Model, Logic + Control,
    View/Presentation

    View Slide

  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

    View Slide

  25. View Slide

  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

    View Slide

  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”

    View Slide

  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”

    View Slide

  29. TDD with FlexUnit, San Jose Flex conf

    View Slide

  30. Formality ties closely with HEAVY, strict and
    regulated documentation

    View Slide

  31. Let’s distill the enterprise!

    View Slide

  32. Purpose of such formality is: audits, culpability
    and validation of public spending

    View Slide

  33. View Slide

  34. View Slide

  35. View Slide

  36. Clean architecture

    View Slide

  37. View Slide

  38. View Slide

  39. View Slide

  40. Onion architecture

    View Slide

  41. View Slide

  42. How to use Onion architecture?
    CLIENTS use services
    DIP – Dependency Inversion Principle

    View Slide

  43. Domain-driven design
    Thank you Sławek Sobótka and Bottega
    folks for some pics

    View Slide

  44. View Slide

  45. View Slide

  46. View Slide

  47. View Slide

  48. View Slide

  49. View Slide

  50. Ports and adapters

    View Slide

  51. View Slide

  52. View Slide

  53. View Slide

  54. View Slide

  55. View Slide

  56. What’s it about?

    View Slide

  57. View Slide

  58. Too perfect
    to be true

    View Slide


  59. devil’s in the…
    pipes

    Dumb pipes,
    heavy automation

    CFT limits you
    – Your org does too

    Network kills you

    View Slide

  60. View Slide

  61. Books

    View Slide

  62. View Slide

  63. Courtesy of Prophecy of Design Patterns

    View Slide

  64. View Slide

  65. Summarizing
    And distilling

    View Slide

  66. Design flaw

    Feathers quadrant

    On files: # changes, McCabe’s cyclomatic complexity

    Upper right corner

    View Slide

  67. No architects

    If it’s trauma – see a specialist

    Brooks would disagree

    Everybody does it? Nobody does

    Senior folks

    Coding architects, of course

    View Slide

  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)?

    View Slide

  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!

    View Slide

  70. Everybody struggles with it

    View Slide

  71. Differs per case, per project

    View Slide

  72. Differs per case, per project
    So choose your type each time

    View Slide

  73. Distilling
    architectures
    from to
    Tomasz Borek, MITORIDAFI
    &

    View Slide

  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, ...

    View Slide

  75. View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  79. View Slide

  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

    View Slide

  81. View Slide

  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!

    View Slide

  83. Too perfect
    to be true

    View Slide

  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

    View Slide

  85. View Slide

  86. View Slide

  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

    View Slide

  88. From enterprise to
    µservices
    Tomasz Borek, MITORIDAFI
    &
    Questions?
    q→ q+1, 0 < q<=20, q<=0
    Feedback is welcome!

    View Slide