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

Software Architecture

Software Architecture

The Architecture Hamburger: Layers, Hexagons, Rings with Onion and Clean Architecture. Last held on 2021.

575ca492bac55e895d0e1c86f7d709fe?s=128

Henning Schwentner

September 23, 2021
Tweet

Transcript

  1. Starring Directed By Special Appearance Presented by With

  2. None
  3. None
  4. 🇩🇪

  5. Java old! C# ABAP PHP Python

  6. None
  7. Buy it on Amazon.com: https://amzn.to/3nF34nI

  8. Kauf mich bei Amazon: https://amzn.to/2ZrcpWc

  9. @hschwentner “A Short History of Software Architecture”

  10. @hschwentner No Architecture Program

  11. @hschwentner No Architecture Mess

  12. @hschwentner 2 Layer Architecture Program DB “uses” Legend:

  13. @hschwentner Foundation Edsger Dijkstra David Parnas information hiding structured programming

    Programming R. Morris Techniques Editor On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched. Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design CR Categories: 4.0 Introduction A lucid statement of the philosophy of modular programming can be found in a 1970 textbook on the design of system programs by Gouthier and Pont [1, ¶I0.23], which we quote below: 1 A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching. Usually nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means of examples, suggest some criteria which can be used in decomposing a system into modules. Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part A Brief Status Report The major advancement in the area of modular programming has been the development of coding techniques and assemblers which (l) allow one module to be written with little knowledge of the code in another module, and (2) allow modules to be reas- sembled and replaced without reassembly of the whole Edgar Dijkstra: Go To Statement Considered Harmful
  14. @hschwentner The One Rule above below Acyclic Dependency Principle allowed

    forbidden
  15. @hschwentner 3 Layer Architecture Presentation Logic Data

  16. @hschwentner 4 Layer Architecture

  17. @hschwentner Patterns Ralph Johnson Erich Gamma Richard Helm John Vlissides

    a.k.a.: Gang of Four
  18. @hschwentner Layered Architecture Frank Buschmann et al.

  19. @hschwentner Strictness allowed forbidden non-strict strict

  20. @hschwentner Infrastructure 4 Layer Architecture User interface Application Domain

  21. @hschwentner The Problem Infrastructure User interface Application Domain

  22. @hschwentner The Problem Domain Infrastructure bank transaction Oracle DB

  23. @hschwentner From above/below to inside/outside above below inside out- side

  24. @hschwentner Hexagonal Architecture Foto: Fotograf Dennis Hamilton/Alistair Cockburn/flickr/CC BY 2.0

    h"p://alistair.cockburn.us/Hexagonal%2Barchitecture Alistair Cockburn
  25. @hschwentner Hexagonal Architecture Foto: Fotograf Dennis Hamilton/Alistair Cockburn/flickr/CC BY 2.0

    h"p://alistair.cockburn.us/Hexagonal%2Barchitecture adapter port adapter port Alistair Cockburn
  26. @hschwentner Kinds of Ports - For UI etc. - Methods

    to be called - “from above” - For DB and infrastructure - Interfaces to be implemented - “from below”
  27. @hschwentner Kinds of Ports Legend:

  28. @hschwentner The Solution

  29. @hschwentner uses implements Legend:

  30. @hschwentner Dependency Inversion Depend on abstractions, not on concretions! Robert

    C. Martin “Uncle Bob”
  31. @hschwentner Onion Architecture U I “application core” domain services domain

    model infra app ture struc serv lication ices 🧅
  32. @hschwentner The 4 Tenets •The applica)on is built around an

    independent object model •Inner layers define interfaces. Outer layers implement interfaces •Direc)on of coupling is toward the center •All applica)on core code can be compiled and run separate from infrastructure Jeffrey Palermo 🧅
  33. @hschwentner Designed for Testability “All application code can be compiled,

    run, and tested separate from infrastructure” Easy unit tests Plays well with TDD 🧅
  34. Clean Architecture Robert C. Martin “Uncle Bob” interactor = use

    case object U I entities DB devices w eb controllers use cases gatew ays presenters
  35. @hschwentner Model—View—Controller controller view model Variants: Model—View—Model Model—View—Viewmodel Trygve Reenskaug

  36. @hschwentner Domain-Driven Design Eric Evans

  37. Entity Value Object Aggregate Service Factory Repository Tactical Design

  38. @hschwentner Entity vs. Value - Identity - Life cycle -

    Can be mutable - No identity - Always immutable Contract Map Name Amount Length 12.5 m $ 100.00 “John Miller”
  39. @hschwentner Repository repository interface repository implementation DB uses impleme port

    adapter Legend:
  40. @hschwentner Architecture Hamburger coarse grained

  41. @hschwentner Architecture Hamburger fine grained view

  42. @hschwentner Don’t: Build one Giant 🍔

  43. @hschwentner Do: Make it a Menu 🍟🍔🥗

  44. None
  45. Buy it on Amazon.com: https://amzn.to/3nF34nI

  46. Kauf mich bei Amazon: https://amzn.to/2ZrcpWc

  47. None
  48. None
  49. None
  50. Henning Schwentner @hschwentner hs@wps.de DDD DDD Slides: speakerdeck.com/hschwentner Book: domainstorytelling.org

  51. @hschwentner Bibliography