,
4 tweets,
2 min read
Read on Twitter
#DomainDrivenDesign is not aggregates, event sourcing, CQRS, event storming etc. These are instruments. They have been shown to be very useful in DDD-minded projects. But we must be careful not confuse the Instrument with the Art.
To me, this is the key insight of DDD: When battling complexity in large systems, how project teams acquire domain knowledge, how they build, evolve and pervasively apply conceptual models, and how they protect the integrity of these models over time trumps technology.
DDD is about lifting the technology veil and seeing more fundamental forces at work in large software projects. DDD gives us a conceptual framework (domain models, bounded contexts, core domains, context maps) to map out and navigate the often hidden shoals of complexity.
A reminder that @ericevans0 and @thepaulrayner are co-teaching a 4-day #DomainDrivenDesign Immersion course here in beautiful Portland, Maine from May 21 thru 24. I hear there are a few seats left.
domainlanguage.com/training/publi…
domainlanguage.com/training/publi…
