In Edge Case Bill de hÓra points out, as does Tony Coates, that a DataClass is not always a bad idea. Both are responding to an assertion made by Martin Fowler, that a DataClass is usually a sign of poor design. And both use serialised objects as a counterexample. I guess I’ve never thought of serialised objects as capable of having behaviour (since they generally live in media that don’t support it); and so perhaps I don’t even think of them as being sufficiently objecty to even count in the discussion. So to me it’s a non-disagreement.
More interesting to my eyes is Bill’s use of the term “application edges”:
“But when it comes to working at the application edges – at the network boundary, over HTTP, between applications, intra-app messaging – well, “I have a doubt.” […] There’s a lot of system edges these days, and agreeing where the edges are is hard.”
There are indeed a lot of edges these days. And trying to think about them in the context of a layered model of the application’s architecture is likely to cause brain-ache. Which is why I keep pushing the hexagonal architecture model. It moves the application and domain objects into the centre, and surrounds them with adapters that connect to the rest of the world. In this architecture, the “edges” have a natural symmetry, and their role in the application becomes easier to visualise.
So in the context of hexagonal adapters, some of Bill and Tony’s data classes will likely be GoF Mementos, others are probably Whole Value objects, and the rest probably really are blobs of data. I would expect the Whole Value objects to have behaviour, but not the others. But the real point, for me, is that the hexagonal architecture approach makes the use of these patterns clearer…