From Concept to Code: Domain-Driven Design for .NET Business Applications
summary
Claim: applying Domain Driven Design makes .NET code reflect actual business language and ownership by splitting a messy monolithic customer model into bounded contexts for sales support and billing. Implementation details: entities, value objects, aggregates, and domain events coordinate changes, with recommended patterns like Clean Architecture, CQRS, event sourcing and tools such as repositories, EF Core and MediatR plus adapters/anti‑corruption layers. Outcome: reduced ambiguity and looser coupling at the cost of added complexity, data duplication and a gradual rollout requirement.
AI-written summary · about
chapters (14)
- 0:00Introduction to Domain-Driven Design in .NET
- 1:03Developer vs business knowledge
- 2:16Monolithic customer system problem
- 4:22DDD and bounded contexts
- 6:30DDD philosophy and practices
- 7:56Ubiquitous language
- 10:23Bounded contexts and teams
- 12:13Business complexity and DDD
- 13:42Tactical design: entities and value objects
- 15:50Aggregates and consistency
- 17:38Domain events for loose coupling
- 19:49DDD pitfalls and best practices
- 23:03DDD tools and patterns
- 24:50References and closing
related talks
52mDDD in Action
20mCraft, TDD, DDD... Should I Feel Guilty for Not Doing Them?
48mSpring is bootiful but so is your domain
43mDomain-driven Data Science
38mTighten the belt and do not suffocate
39mLearning to Love DDD - a Tale of Two Products
40mStop punching yourself in the face!
46mWhat Comes After Going to Production?