Nels, I agree with you that the view, “model your domain and turn each concept into a class”, is too simplistic. An OO program is invariably much messier than its domain model (e.g., because of language shortcomings, such as bi-directional relationships in Java), but that’s not even the whole problem. I think it is fundamentally a mistake to think about the problem (domain model) and the solution (OO program) as mirror images. The OO program is designed to meet non-functional requirements, and those first of all dictate certain decisions to make the program, I don’t know, faster or maintainable. And then it turns out that what we do in the model world, mixing data and behavior, is not what we do in the program.

In my experience it is very very beneficial to separate out data and behavior. In other words, some classes in the program just encode the data, like the famous “Student” class with fields like firstName and lastName. But that class doesn’t have a “graduate” method; that method is in some “manager” class. So fundamentally, we’re ripping our domain model apart and allocate behavior essentially arbitrarily somewhere in the program. What remains is the data, which encapsulates the “state of the world” part of our domain model.

Now that data part, I think, can, modulo practical issues like bi-directionality, resemble the model very closely in code. One may want to re-group things here and there, or make distinctions that are not in the model, but that’s about it. Incidentally, this is the part we like to store in databases, and so this separation also makes sense because we can hand those data objects, which is what they’re actually sometimes called (or “value” objects), to Hibernate or some other persistency layer. This is really really common in enterprise systems. EJBs practically force you to make a separation like this, and they even have names for it, Entity Beans for the data and Session Beans for methods that operate on that data (i.e., for the behavior).

I have a suspicion that other separations like this may also be beneficial, but this is a very common, useful, and familiar one to me. And it makes the domain model be fundamentally different from the code.

OK, enough for now, let me know what you think, and I’ll try to come up with more wisdom about the differences between problem and solution. Btw, I learned to call these two parts “analysis” and “design”, and even if they use the same notation (UML) it doesn’t mean they’re the same at all.