Model Pollution - Speaker Deck

Slide 1

Slide 1 text

Separation ofConcerns Starring Directed By Special Appearance Introducing DDD With Model Pollution is Bad— What Can I Do about It? A Henning Schwentner Talk An Integrated Banking Example and Information Hiding Architecture Hamburger Dependecy Inversion

Slide 2

Slide 2 text

Metro Goldwyn Lolcat

Slide 3

Slide 3 text

Hi, I’m Henning

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

@hschwentner Software != End in itself

Slide 9

Slide 9 text

@hschwentner Software is build Tech people business people for for by

Slide 10

Slide 10 text

@hschwentner (Application) Programming 1. Learn about a domain 2. Build a model for it 3. Add technology to build the system: • programming language • UI • database • …

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

@hschwentner Example: A Banking Domain computer Banking 3000

Slide 13

Slide 13 text

@hschwentner Programming 1. Learn about a domain 2. Build a model for it 3. Add technology to build the system: • programming language • UI • database • …

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

https://hschwentner.io Read on in:

Slide 16

Slide 16 text

https://hschwentner.io Read on in:

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

@hschwentner Programming 1. Learn about a domain 2. Build a model for it 3. Add technology to build the system: • programming language • UI • database • …

Slide 19

Slide 19 text

@hschwentner Rules of thumb:

Slide 20

Slide 20 text

Objects from real world turn into objects in software

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

Actions from real world turn into operations in software

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

=> Object-orientation

Slide 25

Slide 25 text

@hschwentner Programming 1. Learn about a domain 2. Build a model for it 3. Add technology to build the system: • programming language • UI • database • …

Slide 26

Slide 26 text

@hschwentner Coupling • thus we build coupling. we couple the system to technology • => it’s a good idea to localize that coupling! • => that’s one of the reasons for modularity

Slide 27

Slide 27 text

@hschwentner History

Slide 28

Slide 28 text

@hschwentner No Modularity goto goto Program: goto goto goto == chaos

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

@hschwentner Information Hiding David Parnas interface implementation 1972

Slide 31

Slide 31 text

@hschwentner Separation of Concerns Edsger Dijkstra “…study in depth an aspect in isolation […], all the time knowing that one is occupying oneself only with one of the aspects.” one aspect in isolation 1974

Slide 32

Slide 32 text

@hschwentner Separation of Concerns ➢ Single responsibility principle ➢ do one thing well ➢ Change because of one reason ➢ Separation of business logic and technical code

Slide 33

Slide 33 text

@hschwentner Loose Coupling/ High Cohesion Ed Yourdon Larry Constantine in which direction? 19XX

Slide 34

Slide 34 text

@hschwentner Layered Architecture

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 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 38

Slide 38 text

@hschwentner 3 Layer Architecture Presentation Logic Data

Slide 39

Slide 39 text

@hschwentner 4 Layer Architecture User Interface Application Domain Infrastructure

Slide 40

Slide 40 text

@hschwentner Patterns for the Domain Layer

Slide 41

Slide 41 text

@hschwentner Domain Logic Patterns Martin Fowler

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

@hschwentner Rules of thumb:

Slide 44

Slide 44 text

Objects from real world turn into objects in software

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

Actions from real world turn into operations in software

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

=> Object-orientation

Slide 49

Slide 49 text

Values from real world turn into values in software

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

@hschwentner Domain-Driven Design Eric Evans

Slide 52

Slide 52 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?

Slide 53

Slide 53 text

@hschwentner Entity vs. Value − Identity − Life cycle − Can be mutable − No identity − Always immutable Contract Map Name Length 12.5 m “John Miller” Entity Value Object

Slide 54

Slide 54 text

@hschwentner Entity Value Object Aggregate Service Factory Repository Tactical Design

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

@hschwentner The Problem with Layers

Slide 57

Slide 57 text

@hschwentner The Problem Infrastructure User Interface Application Domain BAD!

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

@hschwentner Beyond Layered Architecture

Slide 60

Slide 60 text

@hschwentner below above From above/below to inside/outside outside inside

Slide 61

Slide 61 text

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

Slide 62

Slide 62 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 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

@hschwentner uses implements Legend:

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

@hschwentner Onion Architecture “application core” domain services domain model

Slide 68

Slide 68 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 69

Slide 69 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 70

Slide 70 text

@hschwentner Clean Architecture Robert C. Martin “Uncle Bob” interactor = use case object entities

Slide 71

Slide 71 text

The price of cleanness is eternal mapping

Slide 72

Slide 72 text

Explicit Architecture Herberto Graca

Slide 73

Slide 73 text

@hschwentner Putting it all together

Slide 74

Slide 74 text

@hschwentner Architecture Hamburger Application Domain Infrastructure UI Henning Schwentner

Slide 75

Slide 75 text

@hschwentner Architecture Hamburger 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 76

Slide 76 text

@hschwentner What about Spring, JPA, Hibernate & co.?

Slide 77

Slide 77 text

@javax.persistence.Entity class BankAccount { /*...*/ } @javax.persistence.Embeddable class Amount { /*...*/ }

Slide 78

Slide 78 text

import javax.persistence.*; @Entity class BankAccount { @Id IBAN iban; @Embedded Amount balance; /*...*/ } @Embeddable class Amount { /*...*/ }

Slide 79

Slide 79 text

import javax.persistence.*; @Entity class BankAccount { @Id IBAN iban; @Embedded Amount balance; /*...*/ } When you use this You have to have this …and a default constructor …and you can’t have final fields

Slide 80

Slide 80 text

import javax.persistence.*; @Entity class BankAccount { @Id final IBAN iban; @Embedded Amount balance; /*...*/ } the identity should never change …and it should be initialized at creation, i.e. in the constructor

Slide 81

Slide 81 text

import jakarta.persistence.*; @Entity class BankAccount { @Id final IBAN iban; @Embedded Amount balance; /*...*/ } when someone changes the technology, we have to change the business logic, too

Slide 82

Slide 82 text

@hschwentner LeasingNinja https://leasingninja.io

Slide 83

Slide 83 text

@hschwentner DEMO leasingninja-java-bigballofmud-anemicdomainmodel leasingninja-java-boundedcontext-domainmodel leasingninja-java-boundedcontext-polluteddomainmodel

Slide 84

Slide 84 text

xMolecules

Slide 85

Slide 85 text

xMolecules Stephan Pirnbaum

Slide 86

Slide 86 text

import org.jmolecules.ddd.annotation.*; @Entity class Account { @Identity public final IBAN iban; public void deposit(Amount amount) //... public void withdraw(Amount amount) //... }

Slide 87

Slide 87 text

@hschwentner Boilerplate and Model Pollution Reduction

Slide 88

Slide 88 text

@hschwentner Domain-Driven Refactorings • Strategic Refactorings • Tactical Refactorings (Against Big Ball of Mud) Catalog: https://hschwentner.io/domain-driven-refactorings strategic transformation tactical transformation team-organizational transformation • Socio-Technical • Tactical refactorings (Against Model Anemia)

Slide 89

Slide 89 text

https://hschwentner.io Read on in: https://hschwentner.io/domain-driven-refactorings

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

https://hschwentner.io

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

@hschwentner FEEDBACK

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 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 97

Slide 97 text

This has been a presentation Metro Goldwyn Lolcat

Slide 98

Slide 98 text

Henning Schwentner https://hschwentner.io in/henningschwentner [email protected]