Domain Smells: Domain-Data Overcoupling

Code smells tend to attract developer attention. We have automated tooling for many languages that can spot the most obvious ones. But, code smells are low-level problems and have corresponding low-level solutions. But, what about when your application has a clear mismatch between the way it is built and the problem it is trying to solve? What do you do when your application’s architecture and ways of being described are broken? Those are the kinds of problems that vex me from time to time. Domain smells are the kinds of problems that have a really high cost to resolve, because they are usually systemic in nature.

I don’t have any real advice for how to address these kinds of problems, yet. But, I’m sure devoting some thought to it. I want to come up with ways to better identify and tackle these systemic problems, preferably in ways that don’t break the overall system in needless ways.

This week I’ve been mulling over one Domain Smell in particular: misnamed classes. In my current context some of the problems are not really that bad, there’s just a persistent, nagging, inconsistency that bothers me. I find myself correcting Product Managers when they use the correct Domain Model term, with the Data Model term that I work with day in and day out, and that’s obnoxious. We could just rename the Data Model classes to match the Domain Model that we present to our clients, but that even feels like a superficial solution because we don’t really have much of any representation of our Domain Model in our application to speak of. Our Data Model, functionally, is our Domain Model. And, because of the complexity of the work we’re doing, we are stretching that concept pretty darn thin.

To deal with this particular Domain Smell, which probably deserves a grander name that “misnamed classes,” since it really is more than that, would require us to refactor towards actually representing our Domain Model in code as something other than our Data Model. The refactoring path seems pretty clear in that regard, but the implications are wide ranging since there are a lot of moving pieces that are currently coupled to how we are doing things. And, that high degree of coupling is the direct result of the current design swamp we’re in.

So, I guess a good name for this particular smell would be Domain-Data Overcoupling. And, it would be definable as a failure to adequately distinguish the Domain Model from the Data Model that should underly it, leading to such symptoms as class names that don’t accurately represent the Domain Model, enormous Data Model classes that encapsulate behavior not specific to the model in question, and perhaps other things I haven’t yet recognized.

Now, all I need to do is identify a path forward with and for me and my team. That will prove to be the truly difficult task.