Most problem domains (or shall I more appropriately call them business domains?) have a small number of key abstractions that are crucial to understanding the domain. Coupling these abstractions with the right relationships between them is the essence of modeling the system in which a problem occurs and a solution is desirable. The key abstractions are going to be the same more or less irrespective of what your specific system in that problem domain will try to do.
Now, depending on what type of system you end up wanting to build (a real-time monitoring system, a web-based reporting tool, etc.), you will end up introducing other abstractions that represent computer science/software engineering knowledge. However, these will only supplement and not replace the abstractions that are rooted in the problem domain.
In short, if you see the solution domain as distinct from the problem domain, you will run into trouble with your system design.
Of course the concepts of the problem domain will somehow be present in your solution design. But many OO designs try to force a one to one mapping, which doesn't work well in my experience.
Conceptually, the problem domain consists of a number of "stories", each of them useful to explain one aspect of the system, but the stories are inconsistent with each other and they have to be inconsistent in order to clearly state the aspect they focus on. You could say they are denormalized views on the model. Declaring them to _be_ the model destroys their value and/or the model.
Many OO designs try to replace the model proper with one of its views, usually the one that shows what kinds of things are known. In that view it is reasonable to ignore the fact that some parts of a Customer object are loaded in every HTTP request from some cache, some parts have to remain encrypted at all times, some parts are subject to harsh regulatory requirements and have to reside on a different system (like credit card numbers), some parts need to be available for near realtime analytics whereas others are considered archived, etc.
So you may have a security view, an operational view that includes scalability, distribution and deployment, a process/workflow view that focuses on routing and approval, several different analytics and reporting views, and usually some more.
It's a bad idea to take one of those views and an promote it to _be_ the model through which all other views have to be reconstructed on demand. The model will have to be something different and creating it requires a different mindset the one that OO textbooks suggest.
Now, depending on what type of system you end up wanting to build (a real-time monitoring system, a web-based reporting tool, etc.), you will end up introducing other abstractions that represent computer science/software engineering knowledge. However, these will only supplement and not replace the abstractions that are rooted in the problem domain.
In short, if you see the solution domain as distinct from the problem domain, you will run into trouble with your system design.