Model Pollution

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

Metro Goldwyn Lolcat

Hi, I’m Henning

Software != End in itself

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

@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 • …

Photo: Henning Schwentner Let’s look at an example!

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

@hschwentner Example: A Banking Domain computer Banking 3000

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

https://hschwentner.io Read on in:

@hschwentner Rules of thumb:

Objects from real world turn into objects in software

«Entity» BankAccount

Actions from real world turn into operations in software

«Entity» BankAccount withdraw() deposit()

=> Object-orientation

@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

@hschwentner Insertion: History

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

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

@hschwentner Information Hiding David Parnas interface implementation 1972

@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

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

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

@hschwentner Layered Architecture

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

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

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

@hschwentner 3 Layer Architecture Presentation Logic Data

@hschwentner 4 Layer Architecture User Interface Application Domain Infrastructure

@hschwentner Domain Layer and Domain Model

@hschwentner Domain Logic Patterns Martin Fowler

@hschwentner Domain Logic Patterns Martin Fowler • Transaction Script •
Table Module • Domain Model • Anti-Pattern: Anemic Domain Model

@hschwentner Rules of thumb:

Objects from real world turn into objects in software

«Entity» BankAccount

Actions from real world turn into operations in software

«Entity» BankAccount withdraw() deposit()

=> Object-orientation

@hschwentner Is everything in the world an object?

@hschwentner Another rule of thumb:

Values from real world turn into values in software

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

@hschwentner Domain-Driven Design Eric Evans

@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?

@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

@hschwentner Entity Value Object Aggregate Service Factory Repository Tactical Design

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

@hschwentner The Domain Model Lives in the Domain Layer User
Interface Application Domain Infrastructure

@hschwentner The Problem with Layers

@hschwentner The Problem Infrastructure User Interface Application Domain BAD!

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

@hschwentner Beyond Layered Architecture

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

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

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

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

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

@hschwentner uses implements Legend:

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

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

@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

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

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

The price of cleanness is eternal mapping

Explicit Architecture Herberto Graca

@hschwentner Putting it all together

@hschwentner Architecture Hamburger Application Domain Infrastructure UI Henning Schwentner

@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

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

@hschwentner class BankAccount { void deposit(Amount amount) void withdraw(Amount amount)
/*...*/ } class Amount { /*...*/ }} «Entity» BankAccount withdraw() deposit() «Value Object» Amount

@hschwentner class BankAccount { /*...*/ } class Amount { /*...*/
}}

@hschwentner class BankAccount { final IBAN iban; Amount balance; /*...*/
}} class Amount { /*...*/ }}

@hschwentner class BankAccount { final IBAN iban; Amount balance; BankAccount(IBAN
iban) {this.iban = iban} /*...*/ }} class Amount { /*...*/ }} the identity should never change …and it should be initialized at creation, i.e. in the constructor

@hschwentner import javax.persistence.*; @Entity class BankAccount { @Id final IBAN
iban; @Embedded Amount balance; BankAccount(IBAN iban) {this.iban = iban} /*...*/ }} @Embeddable class Amount { /*...*/ }}

@hschwentner import javax.persistence.*; @Entity class BankAccount { @Id final IBAN
iban; @Embedded Amount balance; BankAccount(IBAN iban) {this.iban = iban} /*...*/ }} @Embeddable class Amount { /*...*/ }} When you use this You have to have this

@hschwentner import javax.persistence.*; @Entity class BankAccount { @Id IBAN iban;
@Embedded Amount balance; BankAccount() {} /*...*/ }} @Embeddable class Amount { /*...*/ }} When you use this You have to have this …and a default constructor …and fields cannot be final

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

@hschwentner LeasingNinja https://leasingninja.io

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

xMolecules

xMolecules Stephan Pirnbaum

@hschwentner import org.jmolecules.ddd.annotation.*; @Entity class BankAccount { @Identity final IBAN
iban; Amount balance; /*...*/ }} @ValueObject class Amount { /*...*/ }} NOT JPA entity! xMolecules

@hschwentner Boilerplate and Model Pollution Reduction

@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)

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

Consulting

@hschwentner FEEDBACK

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

This has been a presentation Metro Goldwyn Lolcat

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

Model Pollution

Model Pollution

More Decks by Henning Schwentner

Other Decks in Programming

Featured

Transcript