Downloaded 224 times
Uploaded byDavid Berliner
Refactoring for Domain Driven Design
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.
More Related Content
Similar to Refactoring for Domain Driven Design
![Copy of Presentation - [Your Organization Name]_20250924_181258_0000.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/copyofpresentation-yourorganizationname202509241812580000-251117131601-9744dd2d-thumbnail.jpg?width=640&height=640&fit=bounds)
Refactoring for Domain Driven Design
- 1. Refactoring towards DomainDriven Design DAVID BERLINER
- 2. The sources ofall knowledge:
- 3. Who am I? Developer at BetTech. I've been coding for a decade. @manatok
- 4. “…is a disciplinedtechnique 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 dowe do it?
- 13.
- 14.
- 15. What is considered “code litter”?
- 18.
- 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
- 31.
- 32.
- 33.
- 34. + You don’thave to drink ALL the kool-aid to benefit + See the good side of a messy system + Be consistent
- 35.