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

Model Pollution

Model Pollution

Avatar for Henning Schwentner

Henning Schwentner

July 03, 2025
Tweet

More Decks by Henning Schwentner

Other Decks in Programming

Transcript

  1. 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
  2. @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 • …
  3. @hschwentner Programming 1. Learn about a domain 2. Build a

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

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

    model for it 3. Add technology to build the system: • programming language • UI • database • …
  6. @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
  7. @hschwentner Structured Programming Edsger Dijkstra Edgar Dijkstra: Go To Statement

    Considered Harmful callable unit callable unit callable unit 1968
  8. @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
  9. @hschwentner Separation of Concerns ➢ Single responsibility principle ➢ do

    one thing well ➢ Change because of one reason ➢ Separation of business logic and technical code
  10. @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”
  11. @hschwentner Domain Logic Patterns Martin Fowler • Transaction Script •

    Table Module • Domain Model • Anti-Pattern: Anemic Domain Model
  12. @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?
  13. @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
  14. @hschwentner The Domain Model Lives in the Domain Layer User

    Interface Application Domain Infrastructure
  15. @hschwentner Kinds of Ports − For UI etc. − Methods

    to be called − “from above” − For DB and infrastructure − Interfaces to be implemented − “from below”
  16. @hschwentner Domain The Solution Domain Infrastructure bank transaction Oracle DB

    Infrastructure bank transaction Oracle DB port adapter
  17. @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
  18. @hschwentner Designed for Testability “All application code can be compiled,

    run, and tested separate from infrastructure” Easy unit tests Plays well with TDD
  19. @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
  20. @hschwentner class BankAccount { void deposit(Amount amount) void withdraw(Amount amount)

    /*...*/ } class Amount { /*...*/ }} «Entity» BankAccount withdraw() deposit() «Value Object» Amount
  21. @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
  22. @hschwentner import javax.persistence.*; @Entity class BankAccount { @Id final IBAN

    iban; @Embedded Amount balance; BankAccount(IBAN iban) {this.iban = iban} /*...*/ }} @Embeddable class Amount { /*...*/ }}
  23. @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
  24. @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
  25. @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
  26. @hschwentner import org.jmolecules.ddd.annotation.*; @Entity class BankAccount { @Identity final IBAN

    iban; Amount balance; /*...*/ }} @ValueObject class Amount { /*...*/ }} NOT JPA entity! xMolecules
  27. @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)
  28. @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.”