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
   &
   

   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