I'd never heard of domain driven design before your post. A quick look at a couple of references - here and here - seem to suggest that it's just a fancy name for the traditional 90s method of object-oriented programming that I was taught in university, where you try and write classes for each noun that appears in the situation you're trying to model with software, so that the structure of the software seems to follow the structure of the real-world concept.
As such, my answer to this is that it's not "good". It's usually a reasonable starting point but proves to be inadequate as you go along. You rarely have a single domain but several different domains within one piece of software - for example, you may have the domain of the game (the world, the characters, the items), the domain of the renderer (the shaders, the meshes, the materials), the domain of input (the filesystem, the network, the keyboard and mouse), and the problems come in where the domains overlap and influence each other. Often in the course of joining 2 domains together, you realise that there is actually a dependency there that requires a change, meaning one of your representations becomes more of a burden than a help.
A vague example might be a mathematics library on a console and your in-game characters. Your maths library will like to have a large list of data and then 1 instruction to perform on that list, to run efficiently. Your in-game characters will each have their own set of vertex data for rendering and animation etc. Now, how do you get a long list of all the vertex data from each of your characters to be able to handle it in one go? You could perform a slow copying operation, or instead you could refactor your characters so that their data is more amenable to being processed by the mathematics library - but then one of your domains is breaking down to favour another one.
Personally I am very wary of any label that resembles "Whatever-Driven-Design". Software is both too wide-ranging and too complex for there to be a one-size-fits-all approach to creating it. Instead, when trying to write the best software I can, I try and fall back on the SOLID principles. These give you a good idea of how good your code is, without promising a panacea of a method that you can follow and magically arrive at good code. Unfortunately, without such an attached methodology, it takes a lot of experience before you learn how to conform to these guidelines, which is probably why so many people like the methodologies.
Regarding your issue of having anaemic classes and manager objects, this is usually something that is covered in introductory object orientation lessons and doesn't really require you adhere to any special methodology to 'fix' it. (You might want to pick up a book on object oriented programming if you're just starting out.) A class is a coupling of state and behaviour, where the behaviour modifies that state, and this is called encapsulation. Generally you try and encapsulate as much as possible, which means that the state should be manipulated by the object itself (and only that object). Only for behaviour that cannot be modelled within the class would you delegate to an external class, such as a manager, which is why the existence of manager classes is often considered a sign of poorly-written object-oriented code.
My current design pattern is in Singleton and I want to do some recoding to get this stuff out.
I don't know what you mean by that line. A design pattern is a well-known way of writing a small part of your program. You wouldn't have a 'current' design pattern, nor would it shape the rest of your program. For beginners, these patterns are useful for getting you on the right track, whereas for experts they're more of a way to communicate about common code situations. One thing is important however: singletons are almost always a bad idea, and you should avoid them whenever possible. You can find many opinions about singletons on this site and over on Stack Overflow, but here is one practical question with answers that help you avoid needing them.