As of the time that this answer was written, the other posted answers here are all wrong.
Instead of asking whether or not Domain-Driven Design is good for games. You should ask whether or not "Domain Modeling" is good for games.
Is domain modeling good for games?
The answer is: sometime it's absolutely fabulous. However, if you're creating a real-time game such as a platformer or FPS or whatever (MANY MANY kinds of games) then no. It's not necessarily well suited for those systems. However, there may be systems within that those games in which implementing the domain model pattern is effective.
As others have mentioned here, component-entity frameworks tend to be very popular, and for good reason. However, in game-development culture there seems to be a distinct lack of layered architectures. Again, this is for good reason as most games that people are going to develop just mutate state on entities and let the emergent consequences be the game.
ALL SOFTWARE IS NOT THE SOFTWARE THAT YOU ARE WRITING. Some are quite different from others.
Some examples of domains in which domain modeling works well are card games, board games, and other types of systems that are event-driven.
Games that run at X frame rate with movement etc determined by time deltas as core domain concepts are probably not a great fit. In this case, our "domain" is often so simple that there's no need for domain modeling. Collision detection, spawning of new entities, influence of forces on existing entities etc tend to cover most gameplay.
However, as things become complex you do start to see developers implementing domain models within their entities to handle certain types of behavior and calculation.
Domain model pattern in game architectures
Your game engine (for example, Unity3D) is often component-entity oriented. In a platformer, you may have an entity for your character and its state is constantly mutated to update position etc.
However, in a more event-driven game, it's more likely that the component-entity framework's role is more to just exist as the User Interface. You end up with a layered architecture.
UI renders game state to the user.
User interacts with the UI, triggering commands in the service layer.
Service layer interacts with domain objects.
Domain objects raised domain events.
Event listeners hear the events and trigger changes in the UI.
UI > Service Layer > Domain Model
In short, end up with model-view-controller with a service layer implementation.
Using this architecture, you have a completely unit-testable game core (A rarity in game development culture, and it shows) with an event-driven interface.
Ok now, what is DDD?
Domain-Driven Design specifically is a culture / movement of emphasis on analytic patterns which are used to learn about the domain, so that you're actually building the right thing, and then implementation patterns that empower you to implement a model layer that represents the concepts in the domain model using your language's idiom. DDD comes out of a community that works with complicated domains and is always seeking for ways to manage high complexity in their applications by focusing on domain modeling.
DDD doesn't do so well if your goal is to just start coding, play around with the system and then figure out what you want to build later, etc. It assumes that there's more or less a domain in existence. So, if you have no idea what your game is going to be.. Then, it's not going to work.