Anaemic Data Model vs Rich Data Model.
I’m gonna keep this simple. I’m not going to enter into a lengthy debate with myself. I’m not going to support my opinion by quoting other TLAs as if their mere existence bestows inarguable acceptance. These are my words on my domain – my opinion – and that is all they need to earn the right to be here.
I don’t like the RDM (OOP encapsulation) because it mixes implementation with design. I would like to specify how an object is represented, but shouldn’t bundle the functionality such that you need to consume my client library in a specific language to be able to take part in my service. Let’s assume that some API boundary is going to require that objects are transferred in a basic serialised form. What good will come of one side of my API having an understanding of that object (a RDM class) that the other cannot benefit from.
IF this API boundary is likely to exist (and I accept that some people may be designing for an environment where this isn’t necessary, and whose mileage will therefore vary) then it makes sense to simplify the serialisation to an interface (readily implementable in pretty much any language) and to implement the ‘doing’ as a Command API.
What about invariant integrity? Shouldn’t I at least protect my properties from duff values in my setters? No. If your class can’t be instantiated or initialised with the incoming data then what would you rather have – a true representation of the incoming data (albeit ones which fails “validation”) or a null object/exception? Surely the former is more useful to you. Don’t have inflexible classes which outright refuse to represent dodgy data. Allow the dodginess (within reason – e.g. you don’t need to keep properties which don’t belong, but you should retain bad values of the right type) and cope with it later in an elegant manner.
My arguments here reflect a scenario wherein the consumer is completely unknown to the API host, cannot have limitations applied to it, and might provide invalid values which we want to deal with sensibly. As such, we need as anaemic a data model as possible, whilst still exposing functionality (including validation) via another means – i.e. not classed based.
If you have different assumptions in your environment then you could well arrive at a different answer. Let’s not argue, but assume that I am right for mine and you are right for yours.
Recent Comments