You are Not my Type

What did the infrastructure code say to the domain class?

You are not my type!

Too Good To Be Used

You don’t need fussy infrastructure code? Fussy code doesn’t pull its weight.
You say = “Map this XML file into a graph of domain objects”
It says = “No”

Once the infrastructure code says to the domain classes – you are not my type! – your only option is to clone (duplicate) the infrastructure code which has just developed a “Sandra Dee” complex.

A Sandra Dee Complex

An infrastructure class that has developed a Sandra Dee complex is very picky. You’re not my type. And you’re not my type. “Get your filthy paws, off my silky drawers”. How has this infrastructure class become too good to be used?

And once you clone this shrinking violet of an infrastructure class – all you get is more shrinking violets. Do you remember what infrastructure code is supposed to do. Let’s remind ourselves.

What does Infrastructure Code Do?

Monogamy between infrastructure and domain classes is not a good thing. But what is their relationship based on? What does infrastructure code do?

Infrastructure code maps something that is not in the “domain object model” to something that is – and vice versa. The most common infrastructure code

  • converts XML data into a graph of domain (business) objects
  • marshals domain objects (flattens them) into an XML representation
  • takes a UI form (name and address) and creates an object
  • straddles objects between the ORM layer and relational databases

It seems “obvious” that infrastructure code must know the intimate details of domain classes in order to create them and stream (store) them. Absolutely Not! And definitely Yes!

What- at the same time? No, not at the same time. You want separation of concerns, monogamy inc – at design time (compile time). But at runtime you want promiscuity and intermingling of the highest order. Whatever the type!

Promiscuity At Runtime

In some ways the term “separation of concerns” is a misnomer. You want your classes to be promiscuous, at runtime.

Infrastructure classes must not be explicitly wedded to domain classes. They very often are and these are marriages of convenience. They are convenient for the developer, who brings them together but not for the object populous at large.

If you hear a software developer asking “Does anyone know of any reason why these two classes should not be joined together in holy matrimony – speak now or forever hold your peace” – shout madly and wave this post in the air.

Type shouldn’t be a problem

You want your infrastructure classes to jump into bed with any plain old java object. Type shouldn’t be a problem. Separate the concerns and the updated conversation between you and your new “no strings attached” infrastructure classes will go like this.

You Say = “Hey, infrastructure class, please unmarshal this new XML into these new domain classes”
It Says = No problem, I’ll get to it right away!”

Leave a Reply

Your email address will not be published. Required fields are marked *