Domain-Driven Design now and in .NET
I advocated DDD for years more as a design methodology than as a set of practical coding rules. Frankly, though, I never felt on my own skin the living power of the concept I was myself advocating.
In more naive terms, I never ate entirely my own dogfood not much because I didn't like it at all but more because I never was hungry enough to eat it.
In addition, no matter the public speaking between DDD and the .NET ecosystem it was never full love.
The summary of my thoughts regarding DDD is: make the conceptual pillars (ubiquitous language, bounded domains, context maps) your own pillars and make any effort to write clean code, as expressive and fluent as you can. Regardless of the business domain. Now? About 15 years after the epyphany of DDD, the pillars are as solid as ever and close enough to be awarded the rank of universal software design principles. They drive you to a deeper understanding of the domain which is key to plan effective software. Other methodologies (ie, event storming) appeared in the mean time to support this vision. All the coding rules pushed around it in books and courses, instead, are largely ineffective — though not harmful.
Software born to be a tool to automate tasks; now it is a tool to mirror life scenarios. Hence, it has be to designed driven by nature of the domain.