Coding, after all, is just writing.

– Jeff Atwood

Yup. Jeff covers some essential aspects of the curious relationship between writing and coding in his post, focusing on the perspective of style and readability. I’ll now give a shot on extending on that topic. I’ve been kicking around the subject of domain modeling in my post drafts bin for quite a while, not knowing how to present it. Today it hit me during a sprint review at a client. There is nothing revolutionary here. It’s all basic domain modeling and design patterns, but viewed from a different angle.

Numerous are the times I have come across inconsistencies in domain models due to misunderstandings in the development process from the actual domain to object model. I’m sure you have too, and this is nothing new under the sun, and to some degree somewhat unavoidable. Perhaps you’ve also seen objects used for something they weren’t meant and designed for. This could be due to architectural shortcomings, laziness or just plain ignorance.

As a harsh example, I’ll describe a case of architectural shortcomings that forced me to do an ugly hack and thus leverage a wrong object for the job at hand. The GUI components of the application featured a parameter-generated form – dubiously titled ViewForm -  for performing complex database queries to ultimately retrieve an entity to open into another form for modification.

First of all, naming the form ViewForm is just a cracker-jack job at crafting an ubiquitous language. It’s a form that views stuff. You must be shitting me. How about SearchForm? After all, it’s a form that searches stuff. Infrastructural domain objects should be named with equal care as the ones in the business end that have taken years and years to refine into concise,  yet semantically clean terms. Ultimately the distilled purpose of the ViewForm component is to search stuff, so I’ll assume from now on that this naming quirk hadn’t been there.

The hack in question? I was asked to implement a search form that queried two separate tables – import and export shipments – and opened a different form depending on the type of consignment the user double-clicked on. I ended up creating a dummy form with absolutely no visual components on it, and some code in the Form_Load (or such, luckily can’t remember a thing of the VB6 API’s) event handler that figured out which of the two consignments it was, opened the corresponding form and closed the dummy one.

The said form performed nicely enough in the job of querying, and being configurable and all that. The problem, however, presented itself when a series of domain modeling mistakes met, reaching a critical mass of code smell. Following are the essential shortcomings that led me to produce probably the ugliest hack I’ve ever had the balls to ship:

1. We’re talking about ERP-style software here, and thus object-oriented programming should be a given. No objects here, other than infrastructural ones, courtesy of VB6 (Form, Control etc). This results in aforementioned search form querying for database rows instead of entities. So no strong typing to be relied on. That also means that refactoring the query form configuration model would’ve been a tedious exercise of implement-and-wait-for-the-bug-reports.
2. When the data schema is modeled merely as database tables and a bunch of functions scattered across random forms all over the place, the domain model easily scatters into a bit of a disorganized mush. In this case, the business requirements dictated that the system should handle import and export shipments, thus the developer creates separate tables for them without stopping for a minute to ponder the semantics of the two. A shipment is a shipment, regardless of its direction, I dare to assert.
3. The configuration data schema for the query form was modeled so that there was a query form definition and it had a bunch of associated column definitions. The gotcha was that the query form definition held the name of the form that would be opened when a user double-clicked a row in the results grid. The semantics of a query form per se come into question here – is query form a query form or a query-and-open-another-form form – but mostly in the sense of separation of concern.

Though all of the aforementioned architectural turds play an important role, the third one is the most essential one in this particular case. The coding-as-writing analogy plays out here in the sense that having a semantically clean ubiquitous language paves the way for clean and pragmatic separation of concern. If the domain model defines a search form, you implement a search form that knows about searching for stuff, and that maybe something needs to be done with the stuff that it finds: something, but not what exactly.

Rather than referring to an individual form to open, the search definition should’ve pointed to a strategy object that would’ve done whatever it wanted with the row of information: figure out a form to open or perhaps perform some other processing on the record. Now I had to emulate that behavior using a Form object to do something it’s not designed nor meant for.

Moving on to unfolding screwup number two. I once tried fishing out a reason for the crowbar-separation of the two shipment directions and got something along the lines of “well it’s because they are a totally different business”. Well humm righty-o, but isn’t a shipment still a bunch of goods that is going from one place to another, results in costs to an array of involved parties and is dictated by a set of legislation, contracts and whatnot?

An imported shipment might hold some information that an exported one doesn’t and vice versa, but object-oriented programming provides inheritance and relational databases provides relationships for just that. Eventually both of the shipment types still need to be treated as equals, just like what happened here. Another highly probable case would be a statistical report on import-to-export ratios.

The key point I’m trying to make here, is that, if the ubiquitous language has been crafted carefully, evaluating semantics provides a logical and robust back bone for designing the object model. Now that I think of it, I can’t see another way to really model a domain. Yet every day I witness failures – albeit smallers ones – in modeling that would’ve been solved by really grinding the terms used to describe the objects.

When an ubiquitous language starts to take shape, go through the terms described and really chew them fine. If the term isn’t concise or unambiguous enough, finetune it until it is. Then use that information to form a pragmatic object model that separates concerns logically.