DDD is a set of principles where you have conversations with your business partners, model scenarios, determine a ubiquitous language, and build software that mirrors those models and conversations. Determining your bound-contexts, their relationship to other bound-contexts, and determining where sub-domains belong. Though this can be confusing since you could have an "order" domain in several bound-contexts with different purposes. It also tends to move away from traditional OO modeling since we're pulling things apart, not abstracting them in order to decouple. I took Eric Evans 5-day class two years ago, but I've been professionally utilizing DDD for about five years including helping build Accenture's new performance management system.

I think the problem is your didn't concretely explain what your method entails and how it is any different from doing a plain HTML website or a Javascript one. Technically, there is a server, and a client, so what do you do exactly on the server and the client and how does it difference from other methods?

It's like someone asking you how does AJAX works and your start discussing functional programming. It doesn't explain what AJAX is and how does it differ from plain server side rendering.

Thanks for the in-good-faith response! I'd say that covers DDD pretty well.

I do still feel that the link between that and your suggestions in the initial comment are still tenuous and vague 'management-speak', but still, thanks for the response :). Obviously I don't know the exact details or how you're running things, so the best I can do is poke at it (in good faith).