21–30 of 97 posts
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned
If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be.
What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
If anything, i find that DDD is underrated and underused. But i can totally imagine projects where it goes completely over the top, like anything (frameworks, patterns, microservices, Redux -oh god Redux-, whatever) Happened the exact same thing with agility when it became Agile™
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.
I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects.
Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely.
With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’.
All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned