I may seem thick-headed for saying this, but if I were building a system to solve a problem related to the management of customers, having something representing the customers themselves would seem integral to the solution. How would I represent the customer data? Is it just stashed in some generic key-value mapped data structure? I would assume it would have to be in the system somewhere.

Maybe I'm just misinterpreting what distinction is drawn between a solution and problem domain. So far, my interpretation is as follows:

* You build objects to represent the machinery involved in the computation (databases, processors, interpreters, etc). These represent your solution domain.

* Anything that explicitly represents the data being computed, rather than just being a container for data collections, is kicked to the weeds as unnecessary and wrong-headed. These would represent your problem domain.

Do I have this interpretation correct? If so, I worry.

I have seen data processors objects become near unmanageable hedges of thorns because the entire conversion from input data to output data is rolled into a GiganticBlobProcessor object. That object containing hundreds, or even thousands of lines of code that means absolutely nothing on their own. This seems prone to its own pitfalls and need for revolutionary changes.

How is this extra scaffolding a net-win? Why can't I take all this processing code, and move it into the definition of the data being translated, which is probably split amongst multiple classes to model relationships?

For instance, I have something representing a sphere within a graphical rendering system, which is capable of responding to requests for its radius, area, volume, intersection with other shapes, etc. Have I already done it wrong? Should I have just a radius primative and then have a SphereDimensionalEvaluator which does the task, being passed the radius?.

I understand the point made by the LtU commenter that TaxReport itself is probably little more than a container, since reports don't really do much in a metaphorical sense. But a customer does: it can request actions and computations from other things, and other things can ask the customer things and tell the customer to do some action. Is my thinking about things this way leading me down a very dark alley?

I am now really confused.

You basically put into words what I wanted to explain in the first place.

A system certainly has to map between the objects and the language of the customer problem down into computer science and software engineering concepts, but shouldn't that be down at the lower levels of your system? Top-level architecture seems like it should employ objects that represent the main features of the business domain and the relationships between those features. If your system is modeled in terms of DB connection pools and collections, doesn't that create too large a gulf between the system's eventual users and the system GUI?

Thank you! but it's still not very clear to me. I'm having trouble trying to visualize how this should play out. :\

Sorry, I am not making any comment one way or the other about the OP, simply pointing out that problem domain objects model things users care about and solution domain objects model things the computer cares about.