> You agree with his point that class hierarchies shouldn't necessary model reality. I'm pointing out that this assertion is meaningless, because it completely

> You agree with his point that class hierarchies shouldn't necessary model reality. I'm pointing out that this assertion is meaningless, because it completely misrepresents what is actually done with class hierarchies. The class hierarchies in the domain models (i.e., Chair) is never the class hierarchies used by components in the the service layer (i.e., PhysicsChair). Functional requirements of specific services never sleep into the domain model. Call it bounded context, single responsibility principle, or encapsulation, but even if we play little semantics games a home is not the same as a mobile home. Pinning together unrelated concepts based on the naive belief that sharing a keyword is enough to bundle concepts together just misrepresents the whole issue as a straw man. > Right, that's his point. No,the point is that it's absurd to talk about class hierarchies with this example, based alone on the simplistic idea that having the word "chair" appear in the identifier is all you need to logically bundle unrelated concepts. The example is poorly thought through even through the perspective of a straw man. > Again, that's the point he's making. In terms of modelling the world (...) That's what you are failing to understand: they are not modeling the world. At all. And from the start. Only the domain model (chair) models the world. The rest is not the domain model, but data types used in the service layer to meet functional requirements (i.e., PhysicsChair). Let's put it bluntly: the straw man you are trying to defend is something that no one one the world at all ever mixes up. Ever.