But splitting it out into another class is halfway there already, no? The relations object doesn't correspond to a real domain object anymore. Next step is just to split out all the other components.
You could say that about anything you construct in your model though? Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?
I could write the whole thing as an ECS and call all the objects systems or components, and then they are nouns in the domain?
> You could say that about anything you construct in your model though?
That’s kind of the point, yes, model -> nouns -> objects.
> Stops being OO if it's not somehow similar to an admittedly vague concept of what an object is, surely?
There’s nothing particularly vague about “noun in the domain”; linguistic-based modelling certainly isn’t the be-all and end-all of OOP modelling, but its one of the traditional approaches dating back to the early 80s and its more sophisticated than thr kind of naive tangible-item approach that seems to be set up as a strawman here.
> I could write the whole thing as an ECS and call all the objects systems or components, and then they are nouns in the domain?
A relationship is a real thing in the domain being modelled, “systems” and “components” are (in the sense you are using them) not, unless the thing you are modelling is a an ECS implementation of a domain. There might be some utility for such a second-order model in OOP (if the OOP is for a code generator, for instance), but it wouldn’t be a model of the domain addressed by the ECS system, but of the ECS system itself.
