I've just read about Domain models and it enlightened me since I've been developing a game that has a class which only holds data (few behaviors/methods). I assigned the job of handling these classes to the managers...and now my manager seems to look like a God object. My game object that supposed to be handling the logic is just an anemic domain model.

My current design pattern is in Singleton and I want to do some recoding to get this stuff out. I've never seen a DDD on games (as of now) but is this a good approach? I'm just a novice programmer (inclined to game dev't) so I want to learn more about good architecture before the game gets too bloated for redesigning.

  • 2
    \$\begingroup\$ I can say a popular design for games is a Component architecture. A new design that is getting some play at the bleeding edge of games engines is data oriented design (just means that how the data is placed in memory is the highest design concern really). But I can not speak to Domain Driven Design in video games.. so hence, just a comment. \$\endgroup\$
    – James
    Commented Oct 9, 2011 at 18:06
  • \$\begingroup\$ Games are not business applications. Sound architecture in a business application (DDD/CQRS) is definitely not sound in a game, and visa-versa. Why not research the decorator model, or component model? Those are "good" for games and would alleviate your singleton problem - even in saying that, singletons are usually fine in games; especially if you are doing indie development. Concentrate on finishing something, else you will land up like me with a great architecture, but no game. \$\endgroup\$ Commented Oct 11, 2011 at 14:27
  • \$\begingroup\$ Thanks for the suggestion. I'll read about Component design. I'll finish the game I'm working on even though it's design is not that good. I have a deadline this November lol. I've removed the concept of Singleton and I'm injecting modules to objects that need it. I guess that'll be enough for now but I need to learn more. \$\endgroup\$
    – Sylpheed
    Commented Oct 13, 2011 at 12:34

4 Answers 4


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.

  • \$\begingroup\$ Okay let me change the question a bit. Is there a difference between domain models and domain driven design? My idea about domain models is that a class should be able to handle itself without relying on a controller/manager as much as possible. My current design defeats this purpose. I may be misunderstanding something. So in an RPG game, my player class has its own domain and is composed of different domains like skills, items, etc. \$\endgroup\$
    – Sylpheed
    Commented Oct 10, 2011 at 2:07
  • \$\begingroup\$ Yes, a class should be able to handle itself without relying on a controller/manager as much as possible, but that is nothing to do with domain models and is just a standard approach of object oriented programming. It's not clear what you might be misunderstanding because I don't know why you have these manager classes. \$\endgroup\$
    – Kylotan
    Commented Oct 10, 2011 at 9:39
  • \$\begingroup\$ I don't see how to make my module working without a manager or a class that queries my object. For example, I have a module for quests. For me to access the right quest, I have to query from the manager. So how do I go over this without a manager? \$\endgroup\$
    – Sylpheed
    Commented Oct 13, 2011 at 12:31
  • \$\begingroup\$ What is the 'right' quest? How does the manager know what is right? My guess is that the logic that makes such decisions draws on other objects to make them, and those other objects are better candidates for this functionality. \$\endgroup\$
    – Kylotan
    Commented Oct 13, 2011 at 12:53
  • \$\begingroup\$ Well right now my manager is acting just like a repository after some cleanup. For example, I have 10 live quests. I'm accessing these quests through ID for easier retrieving. So my player has a component for quests (the manager) and I'll access the quest from there. It's still the player who is controlling what quest he can have. Is this a bad idea? \$\endgroup\$
    – Sylpheed
    Commented Oct 13, 2011 at 18:07


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.

  • 1
    \$\begingroup\$ Thanks for the insight. I had this figured out maybe 3 or 4 years ago. I was naive back then (5 years ago) since I always try to fit the "design pattern" to all my problems. Learning these "patterns" and architecture helped since it gave me more options. I always stick to abstracting parts of my code "just enough" so that it'll be easy for designers (very important), unit testing, and future mechanics. Overkilling the architecture made it hard to work with and I learned that the hard way. Right now I have already leveraged component-based architecture to fit my style of coding. SOLID ftw. \$\endgroup\$
    – Sylpheed
    Commented May 27, 2016 at 19:40

No, I don't think DDD, or any other "buzzword" architecture is really good for games. With the possible exception of "component system", which seems really popular here.

When I hear questions and discussions like this, I'm reminded of this site. Pondering various architecture buzzwords will usually do you less good than actually designing and coding your own application.

  • 1
    \$\begingroup\$ +1 for "actually designing and coding your own application." those patterns are guidelines and thought provokers to me - nothing more. Changing a problem so that it fits into a solution is the wrong thing to do. \$\endgroup\$ Commented Oct 11, 2011 at 14:29

Yes, but you should adapted.

When using DDD you will get modularity and single responsibility of each domain. But anything else just make things complex.

See my answer here

  • \$\begingroup\$ You may want to expand your answer a bit (cover the main part of the answer), because right now it is a link only answer (even if it points to another stack exchange site). \$\endgroup\$
    – Vaillancourt
    Commented Sep 2, 2018 at 0:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .