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

Software Architecture

Software Architecture

The Architecture Hamburger: Layers, Hexagons, Rings with Onion and Clean Architecture.

Henning Schwentner

September 13, 2023
Tweet

More Decks by Henning Schwentner

Other Decks in Programming

Transcript

  1. Starring
    Directed By
    Special
    Appearance
    Presented by
    With

    View Slide

  2. View Slide

  3. View Slide

  4. !

    View Slide

  5. Hi, I’m
    Henning

    View Slide

  6. !"#

    View Slide

  7. View Slide

  8. Photo: Henning Schwentner
    Let me
    tell you a
    story

    View Slide

  9. @hschwentner
    Example: A Banking Domain
    bank
    account
    customer
    teller
    computer
    transaction

    View Slide

  10. @hschwentner
    Example: A Banking Domain
    computer
    Banking
    3000

    View Slide

  11. @hschwentner
    Good Architecture
    requires different
    ingredients
    ! "
    #
    $
    %

    View Slide

  12. @hschwentner
    A Short
    History of
    Software
    Architecture

    View Slide

  13. @hschwentner
    Program
    No Architecture

    View Slide

  14. @hschwentner
    No Architecture
    Mess

    View Slide

  15. @hschwentner
    Foundations

    View Slide

  16. @hschwentner
    Structured Programming
    Edsger Dijkstra
    Edgar Dijkstra: Go To Statement Considered Harmful
    callable
    unit
    callable
    unit
    callable
    unit

    View Slide

  17. @hschwentner
    Information Hiding
    David Parnas
    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
    of this material is granted, provided that reference is made to this
    publication, to its date of issue, and to the fact that reprinting
    privileges were granted by permission of the Association for Com-
    puting Machinery.
    Author's address: Department of Computer Science, Carnegie-
    Mellon University, Pittsburgh, PA 15213.
    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
    system. This facility is extremely valuable for the
    production of large pieces of code, but the systems most
    often used as examples of problem systems are highly-
    modularized programs and make use of the techniques
    mentioned above.
    1 Reprinted by permission of Prentice-Hall, Englewood
    interface
    imple-
    mentation
    "
    #

    View Slide

  18. @hschwentner
    Loose Coupling/
    High Cohesion
    Ed
    Yourdon
    Larry
    Constantine
    !
    in which
    direction?

    View Slide

  19. @hschwentner
    Layered
    Architecture

    View Slide

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

    View Slide

  21. @hschwentner
    below
    The One Rule
    above
    Acyclic
    Dependency
    Principle
    allowed forbidden

    View Slide

  22. @hschwentner
    3 Layer Architecture
    Presentation
    Logic
    Data

    View Slide

  23. @hschwentner
    4 Layer Architecture

    View Slide

  24. @hschwentner
    Patterns
    Ralph
    Johnson
    Erich
    Gamma
    Richard
    Helm
    John
    Vlissides
    a.k.a.: Gang of Four
    ! " # !

    View Slide

  25. @hschwentner
    Layered Architecture
    Frank
    Buschmann
    et al.
    . . .
    $

    View Slide

  26. @hschwentner
    Strictness
    allowed
    forbidden
    non-strict strict

    View Slide

  27. @hschwentner
    4 Layer Architecture
    User Interface
    Application
    Domain
    Infrastructure

    View Slide

  28. @hschwentner
    The Problem
    Infrastructure
    User Interface
    Application
    Domain
    allowed
    BAD!

    View Slide

  29. @hschwentner
    The Problem
    Domain
    Infrastructure
    bank
    transaction
    Oracle DB
    Concrete
    BAD!

    View Slide

  30. @hschwentner
    Beyond
    Layered
    Architecture

    View Slide

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

    View Slide

  32. @hschwentner
    port
    port
    Hexagonal Architecture
    Foto: Dennis Hamilton/flickr/CC BY 2.0
    http://alistair.cockburn.us/Hexagonal%2Barchitecture
    adapter
    adapter
    Alistair
    Cockburn

    View Slide

  33. @hschwentner
    Kinds of Ports
    - For UI etc.
    - Methods to be called
    - “from above”
    - For DB and infrastructure
    - Interfaces to be
    implemented
    - “from below”

    View Slide

  34. @hschwentner
    secondary
    port
    primary
    port
    adapter
    adapter
    Kinds of Ports
    Legend:
    Flow of
    control
    Dependency

    View Slide

  35. @hschwentner
    Domain
    The Solution
    Domain
    Infrastructure
    bank
    transaction
    Oracle DB
    Infrastructure
    bank
    transaction
    Oracle DB
    port
    adapter
    Step 1

    View Slide

  36. @hschwentner
    uses
    implements
    Legend:

    View Slide

  37. @hschwentner
    Dependency Inversion
    Depend on
    abstractions,
    not on
    concretions!
    Robert C.
    Martin
    “Uncle Bob”
    !

    View Slide

  38. @hschwentner
    Onion Architecture
    U
    I
    “application core”
    domain
    services
    domain
    model
    infra
    app
    ture
    struc
    serv
    lication
    ices
    %

    View Slide

  39. @hschwentner
    The 4 Tenets
    •The application is built around an independent object model
    •Inner layers define interfaces. Outer layers implement
    interfaces
    •Direction of coupling is toward the center
    •All application core code can be compiled and run separate
    from infrastructure
    Jeffrey
    Palermo
    %
    !

    View Slide

  40. @hschwentner
    Designed for Testability
    “All application code can be
    compiled, run, and tested
    separate from infrastructure”
    Easy unit tests
    Plays well with TDD
    %

    View Slide

  41. Clean Architecture
    Robert C.
    Martin
    “Uncle Bob”
    interactor = use case object
    U
    I
    entities
    DB
    devices
    w
    eb
    control
    use cases
    gate
    presenters
    lers
    ways

    View Slide

  42. Explicit Architecture
    Herberto
    Graca
    $

    View Slide

  43. @hschwentner
    Patterns
    Languages

    View Slide

  44. @hschwentner
    Different Layers—
    Different Patterns
    User Interface
    Application
    Domain
    Infrastructure

    View Slide

  45. @hschwentner
    Patterns
    for the
    UI Layer

    View Slide

  46. @hschwentner
    Model—View—Controller
    controller view
    model
    Variants:
    Model—View—Presenter
    Model—View—Viewmodel
    Trygve
    Reenskaug
    %

    View Slide

  47. @hschwentner
    Patterns
    for the
    Domain Layer

    View Slide

  48. @hschwentner
    Domain Logic Patterns
    Martin
    Fowler
    %

    View Slide

  49. @hschwentner
    Domain Logic Patterns
    Martin
    Fowler
    %
    • Transaction Script
    • Table Module
    • Domain Model

    View Slide

  50. @hschwentner
    Domain-Driven Design
    Eric
    Evans
    !

    View Slide

  51. View Slide

  52. @hschwentner
    Domain Modeling

    View Slide

  53. @hschwentner
    Domain Modeling
    BankAccount
    withdraw()
    deposit()
    Amount

    View Slide

  54. @hschwentner
    BankAccount
    withdraw()
    deposit()
    Amount
    Domain Model

    View Slide

  55. @hschwentner
    Entity Value Object
    Aggregate
    Service
    Factory
    Repository
    Domain Event
    Tactical Design

    View Slide

  56. @hschwentner
    Entity
    Tactical Design
    Value Object
    Is it a thing?
    Is it a property of a thing?
    Can you touch it?
    Is it identityless?
    Does it have an identity?
    Rules of Thumb

    View Slide

  57. «Entity»
    BankAccount
    withdraw()
    deposit()
    «Value Object»
    Amount

    View Slide

  58. @hschwentner
    Architecture Rules
    value object
    entity
    allowed forbidden

    View Slide

  59. @hschwentner
    Expressing Architecture
    https://xmolecules.org

    View Slide

  60. @hschwentner
    Patterns
    for the
    Infrastructure
    Layer

    View Slide

  61. @hschwentner
    domain
    layer
    infra-
    structure
    layer
    Repository
    repository
    interface
    repository
    implementation
    DB
    port
    adapter

    View Slide

  62. @hschwentner
    Domain
    The Solution
    Infrastructure
    transaction
    repository
    Oracle DB
    bank transaction
    repo impl
    Step 2
    Domain
    Infrastructure
    bank
    transaction
    Oracle DB
    port
    adapter

    View Slide

  63. @hschwentner
    Patterns
    for the
    Application
    Layer

    View Slide

  64. @hschwentner
    Use Case
    Event Publisher
    Application Service
    Event Subscriber
    Application Layer Patterns

    View Slide

  65. @hschwentner
    Application Service
    domain
    object
    domain object
    domain object
    domain
    object

    View Slide

  66. @hschwentner
    Putting it
    all together

    View Slide

  67. @hschwentner
    Architecture Hamburger
    Application
    Domain
    Infrastructure
    UI coarse grained

    View Slide

  68. @hschwentner
    Architecture Hamburger
    fine grained
    model
    repository
    interface
    controller
    use case
    service
    entity
    value object
    view
    data
    model
    repository
    implementation
    widget
    library
    REST
    frame-
    work
    transaction
    handling
    domain
    library
    programming
    language
    ORM
    file
    system
    access
    domain event

    View Slide

  69. @hschwentner
    In the
    Large

    View Slide

  70. @hschwentner
    Don’t: Build one Giant !

    View Slide

  71. @hschwentner
    Do: Make it a Menu
    $%&

    View Slide

  72. @hschwentner
    Domain-Driven Design
    Eric
    Evans
    !

    View Slide

  73. @hschwentner
    Banking Domain
    bank computer
    Banking
    3000

    View Slide

  74. @hschwentner
    Banking Subdomains
    account
    processing
    credit
    lending
    stock
    trading
    Banking
    3000

    View Slide

  75. @hschwentner
    Big Ball of Mud
    Banking 3000
    Big Ball of Mud

    View Slide

  76. @hschwentner
    Banking 3000
    Strategic Design
    account
    processing
    credit
    lending
    stock
    trading
    & ' (

    View Slide

  77. @hschwentner
    Architecture Hamburger
    fine grained
    model
    repository
    interface
    controller
    use case
    service
    entity
    value object
    view
    data
    model
    repository
    implementation
    domain event
    model
    repository
    interface
    controller
    use case
    service
    entity
    value object
    view
    data
    model
    repository
    implementation
    domain event

    View Slide

  78. @hschwentner
    Example

    View Slide

  79. @hschwentner
    LeasingNinja
    https://leasingninja.io

    View Slide

  80. View Slide

  81. https://hschwentner.io

    View Slide

  82. View Slide

  83. @hschwentner
    FEEDBACK

    View Slide

  84. View Slide

  85. View Slide

  86. @hschwentner
    Bibliography
    Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael
    Stal. Pattern-Oriented Software Architecture Volume 1: A System of Patterns.
    Hoboken, NJ: Wiley, 1996.
    Cockburn, Alistair. “Hexagonal Architecture.” January 4, 2005.
    https://alistair.cockburn.us/hexagonal-architecture/.
    Dijkstra, Edsger. “Go To Statement Considered Harmful.” Communications of the
    ACM 11, no. 3 (March 1968): 147–48.
    Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software.
    Boston: Addison-Wesley, 2004.
    Fowler, Martin. Patterns of Enterprise Application Architecture. Boston: Addison-
    Wesley, 2005.
    Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns:
    Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley,
    1995.
    Graca, Herberto. “DDD, Hexagonal, Onion, Clean, CQRS, … How I Put It All Together.”

    View Slide

  87. View Slide

  88. Henning Schwentner
    ⌂ https://hschwentner.io
    @hschwentner
    [email protected]

    View Slide