my colleagues and I are having a recurring discussion about separation of functionality/logic.
Personally my view (and perhaps I am stuck in this way of thinking) is to separate data/domain and algorithm/functionality. And I notice I'm quite a purist in that.
My colleagues on the other hand tend to put the functionality over multiple classes that I would consider "data"-classes, or domain classes.
More concretely, we are now implementing a user story that aligns images, grouped by date and image series.
My natural tendency, first reflex, is to start making an ImageAligner class in which I'd implement that feature, using the domain/data. This would have all the "algorithmic" stuff needed for the feature, like grouping by date etc etc, including the alignment logic.
The application would then instantiate that ImageAligner and it would listen to the data/context and do its stuff.
My colleagues argue on the other hand that the ImageAligner class is not needed. They claim it would be fine to put parts of the feature into the domain objects. The feature would be implemented through the collaboration of these domain classes.
One of their other arguments is that, because my solution looks like a strategy pattern, it adds just more complexity. They would even say it's over-engineered. Whereas I find it simpler because it isolates the feature in one place, making it easier to find and modify.
I'm having a hard time convincing them (and they me). Mainly because what I see as domain/data objects, they consider to be functionality/feature classes. Also I have had some very good experiences in the past separating logic and domain in this way, making it hard for me to let go of this pattern of thinking.
Do you strictly separate algorithms/features/logic from domain/data in separate classes?
What would be arguments for choosing the one or the other design?
Or am I just stuck in an odd way of thinking?
Penny for your thoughts.