The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be ca

The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be categorized as "systems design". You either do it with the knowledge of the common sticking points of DDD or you don't. 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.