Slide 1

Slide 1 text

Starring Directed By Special Appearance Presented by With

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Hi, I’m Henning

Slide 4

Slide 4 text

Photo: Henning Schwentner

Slide 5

Slide 5 text

👨💻👨🏫👨💼

Slide 6

Slide 6 text

Carola Lilienthal & Henning Schwentner Foreword by Michael Feathers Modernize Legacy Systems and Mitigate Risk Domain-Driven Transformation

Slide 7

Slide 7 text

Carola Lilienthal & Henning Schwentner Foreword by Michael Feathers Modernize Legacy Systems and Mitigate Risk Domain-Driven Transformation

Slide 8

Slide 8 text

@hschwentner History of Computer Architecture

Slide 9

Slide 9 text

@hschwentner The First Program Ada Lovelace 🇬🇧 “Note G” 1843

Slide 10

Slide 10 text

@hschwentner Proof: a Computer is Possible Alan Turing 🇬🇧 1936 M = ⟨Q, Γ, b, Σ, δ, q0 , F⟩ Which numbers can be computed? … and which cannot? Turing machine

Slide 11

Slide 11 text

@hschwentner First Electrical Computer Konrad Zuse Z3 🇩🇪 1941

Slide 12

Slide 12 text

@hschwentner First General-Purpose Computer ENIAC == Electronic Numerical Integrator and Computer 1945 🇺🇸

Slide 13

Slide 13 text

@hschwentner The First Bug 1947 Grace Hopper 🇺🇸

Slide 14

Slide 14 text

@hschwentner Hardware Architecture 1945 🇭🇺 🇺🇸 John von Neumann von Neumann architecture

Slide 15

Slide 15 text

@hschwentner But What about Software Architecture?

Slide 16

Slide 16 text

Photo: Henning Schwentner Let me tell you a story

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

@hschwentner Example: A Banking Domain computer Banking 3000

Slide 19

Slide 19 text

@hschwentner Good Architecture requires different ingredients 🥒 🧀 🍅 🍞 🧅

Slide 20

Slide 20 text

@hschwentner A Short History of Software Architecture

Slide 21

Slide 21 text

@hschwentner Program No Architecture

Slide 22

Slide 22 text

@hschwentner No Architecture Mess

Slide 23

Slide 23 text

@hschwentner Foundations

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@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 🇨🇦 🇺🇸 hidden accessible 1972

Slide 26

Slide 26 text

@hschwentner Loose Coupling/ High Cohesion Ed Yourdon Larry Constantine 🇺🇸 in which direction? 1979

Slide 27

Slide 27 text

@hschwentner Layered Architecture

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

@hschwentner Fundamental Theorem of Software Engineering David Wheeler 🇬🇧 “We can solve any problem by introducing an extra level of indirection” “…except for the problem of too many levels of indirection”

Slide 31

Slide 31 text

@hschwentner 3 Layer Architecture Presentation Logic Data

Slide 32

Slide 32 text

@hschwentner 4 Layer Architecture

Slide 33

Slide 33 text

@hschwentner Patterns Ralph Johnson Erich Gamma Richard Helm John Vlissides a.k.a.: Gang of Four 🇺🇸 🇨🇭 🇦🇺 🇺🇸

Slide 34

Slide 34 text

@hschwentner Layered Architecture Frank Buschmann et al. . . . 🇩🇪

Slide 35

Slide 35 text

@hschwentner Strictness allowed forbidden relaxed strict

Slide 36

Slide 36 text

@hschwentner 4 Layer Architecture User Interface Application Domain Infrastructure

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

@hschwentner Beyond Layered Architecture

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

@hschwentner uses implements Legend:

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

@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 🧅 🇺🇸

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Explicit Architecture Herberto Graca 🇵🇹

Slide 52

Slide 52 text

@hschwentner Patterns Languages

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

@hschwentner Patterns for the UI Layer

Slide 55

Slide 55 text

@hschwentner Model—View—Controller controller view model Variants: Model—View—Presenter Model—View—Viewmodel Trygve Reenskaug 🇳🇴

Slide 56

Slide 56 text

@hschwentner Patterns for the Domain Layer

Slide 57

Slide 57 text

@hschwentner Domain Logic Patterns Martin Fowler 🇬🇧

Slide 58

Slide 58 text

@hschwentner Domain Logic Patterns Martin Fowler 🇬🇧 • Transaction Script • Table Module • Domain Model

Slide 59

Slide 59 text

@hschwentner Domain-Driven Design Eric Evans 🇺🇸

Slide 60

Slide 60 text

Workshop Domain-Driven Design concrete wps.de/ddd

Slide 61

Slide 61 text

@hschwentner Domain Modeling

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

@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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

@hschwentner Architecture Rules value object entity allowed forbidden

Slide 68

Slide 68 text

@hschwentner Expressing Architecture https://xmolecules.org

Slide 69

Slide 69 text

@hschwentner Patterns for the Infrastructure Layer

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

@hschwentner Patterns for the Application Layer

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

@hschwentner Application Service domain object domain object domain object domain object

Slide 75

Slide 75 text

@hschwentner Putting it all together

Slide 76

Slide 76 text

@hschwentner Architecture Hamburger Application Domain Infrastructure UI coarse grained Henning Schwentner 🇩🇪

Slide 77

Slide 77 text

@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

Slide 78

Slide 78 text

@hschwentner In the Large

Slide 79

Slide 79 text

@hschwentner The First Law of Software Architecture “… architects must always soberly assess the good, bad, and ugly of every choice, and virtually nothing in the real world offers convenient binary choices— everything is a trade-off.”

Slide 80

Slide 80 text

@hschwentner Don’t: Build one Giant 🍔

Slide 81

Slide 81 text

@hschwentner Do: Make it a Menu 🍟🍔🥗

Slide 82

Slide 82 text

@hschwentner Domain-Driven Design Eric Evans 🇺🇸

Slide 83

Slide 83 text

@hschwentner Banking Domain bank computer Banking 3000

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

@hschwentner Banking 3000 Strategic Design account processing credit lending stock trading 🍟 🍔 🥗

Slide 87

Slide 87 text

@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

Slide 88

Slide 88 text

@hschwentner Outlook: Architecture in and for the AI Age

Slide 89

Slide 89 text

@hschwentner Two Directions AI helps to program AI as part of the system supports in the domain Per subdomain: is this an AI subdomain or not? Local changes are easier to check by the human in the loop modularity

Slide 90

Slide 90 text

@hschwentner Example

Slide 91

Slide 91 text

@hschwentner LeasingNinja https://leasingninja.io

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

Carola Lilienthal & Henning Schwentner Foreword by Michael Feathers Modernize Legacy Systems and Mitigate Risk Domain-Driven Transformation

Slide 94

Slide 94 text

Carola Lilienthal & Henning Schwentner Foreword by Michael Feathers Modernize Legacy Systems and Mitigate Risk Domain-Driven Transformation

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

@hschwentner FEEDBACK

Slide 97

Slide 97 text

No content

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

No content

Slide 101

Slide 101 text

Henning Schwentner  https://hschwentner.io  in/henningschwentner ✉ [email protected] Kolleg:in gesucht (Deutschlandweit) Carola Lilienthal & Henning Schwentner Foreword by Michael Feathers Modernize Legacy Systems and Mitigate Risk Domain-Driven Transformation