Technically DDD
summary
Practical DDD approach: start by shipping a guard in the entity to enforce a business rule (e.g., meetings cannot end before they start, program slots cannot overlap in the same room), then implement → extract → refactor into a dedicated value object so invalid state cannot exist, use exceptions and unit tests to keep code shippable, and replace primitives with DateTimeImmutable and domain-specific durations (discovered bugs: inclusive vs exclusive bounds and midnight-crossing rules). Outcome: layered, testable objects and clearer domain intent — the refactors keep behavior while improving meaning.
AI-written summary · about
chapters (10)
- 0:00Intro
- 6:21Value Objects
- 10:40Entities
- 13:16Services
- 15:38Repository
- 20:07Anemic model
- 23:16Implementation
- 27:36Business Rule
- 29:40Program Slots
- 36:42Conclusion
related talks
59mDomain-Driven Design - Where Rubber Meets the Road
58mImplementing Domain Driven Design as a Pragmatic .NET Developer
35mTrivialization of DDD or Not?
42mHigh-Speed DDD (revisited)
50mMoving away from CRUD: DDD + CQRS
38m7 Years of DDD: Tackling Complexity
50mAll Models Are Wrong: Lessons from Real DDD Projects
38mWhat I talk about when I talk about Domain Driven design