Last time left us with a couple of very simple domain objects written in Groovy. No real behavior or anything like that, and at this point they aren't anything that we couldn't have done just as easily with Transfer or even just using queries and structs. It was kind of nice not having to create any database tables, but other than that no real world benefit so far.
Here are the updated files for this post if you would like to follow along.
Even ignoring that we have no behavior in our objects (not the point of this post), what we have is less than ideal, both from the point of view of the object model and for the relational model. Employer and Employee both have 4 properties representing an address instead of just one property that is an address. Wouldn't it be better if say, we could have the address be it's own class? That way we could implement some snazzy behavior in it and not have to repeat that logic in any object that will have an Address?
[More]