Refactoring for Domain Driven Design
80 likes9,165 views
The document discusses refactoring code towards a domain-driven design approach. It notes that over time, as more features are added and teams grow, code becomes more complex without design. Domain-driven design is presented as a way to refactor code through techniques like defining a ubiquitous language, identifying domain models, isolating domains with bounded contexts, and expressing state changes with events. Refactoring requires prioritization and "boyscout refactoring" of cleaning up small pieces of code litter. The document advocates for seeing the benefits of refactoring without having to fully adopt every aspect of domain-driven design or drink the "kool-aid." Consistency is important when refactoring.
Refactoring for Domain Driven Design
- 1. Refactoring towards Domain Driven Design DAVID BERLINER
- 2. The sources of all knowledge:
- 3. Who am I ? Developer at BetTech. I've been coding for a decade. @manatok
- 4. “…is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.…” Martin Fowler
- 7. + Adding features + Shortcuts and hacks + Team growth = increased complexity
- 8. No thanks! We're too busy.
- 9. TIME CUMULATIVE FUNCTIONALITY GOOD DESIGN NO DESIGN DESIGN PAY-OFF LINE
- 10. So... how do we do it?
- 15. What is considered “code litter”?
- 19. Bounded context Ubiquitous language
- 28. Define model with Ubiquitous Language Identify model with MODEL DRIVEN DESIGN Process model with Express model with Express model with Isolate domain with Express state change with Bounded Contexts Services Entities Value Objects Layered Architecture Events
- 33. final thoughts
- 34. + You don’t have to drink ALL the kool-aid to benefit + See the good side of a messy system + Be consistent
- 35. Thaynouk