January 10, 2007

...Learn TDD with Codemanship

Keep Your Domain Model Clean

On most projects, the discipline of keeping our domain model in shape in the code pays dividends later on. I have long believed that the domain model of a software application is like the kitchen of a good restaurant. To ensure swift and efficient service you need to keep your kitchen clean and uncluttered. The same goes for your domain model. It's the heart of your application, and if you let it get messy and unsanitary, you can expect heartache in the later stages of development.

On one project I worked on, there was a very significant reporting element to the application, and the effort invested in maintaining a usable domain model was rewarded several-fold when the team found that new reports could be created very quickly by just navigating across the object graph. Hibernate took care of the technical details of fetching, retreiving, lazy loading and caching and we didn't write a line of code in our business objects that wasn't 100% business logic. We also had very good unit test coverage on our domain classes - made much easier by using Hibernate to keep persistence a totally seperate concern from business logic.

Tests were easier to write and, because we didn't hit the database, ran hundreds of times faster - meaning we could add more unit tests to our test suite. We tested persistence seperately with a much smaller suite of tests. (Though I think we may have needed more, with hindsight.) And although I stand by my claim that there's no free lunch with Hibernate, the fact that we ended up with clean, unfettered POJO's (plain old Java objects) and a domain model that was a more accurate reflection of reality made a big difference in the final score. It should always be that easy.

I also made an effort to maintain a domain model class diagram, which lived on the notice board right by the team in plain view of all and sundry. A clean, unfettered and visible domain model is a positive boon for a team. Now when we discussed the code, we could talk in terms of our domain model, so we had a clearer idea of exactly what we were talking about. It helps enormously to be able to discuss design in purely business terms. Sod the XP practice of metaphor. Get your domain model up on the whiteboard where we can all see it, that's what I say!

On a final note, towards the middle of the project we organised a "show-and-tell" for our client, so they could get a practical demonstration of what we'd built. Accompanying that we threw together a little presentation. One of the key points in our presentation was the potential reusability of the domain model. It was enterprise architecture, but an emergent form of enterprise architecture. We had built something with a specific purpose in mind, but inside what we'd built was a set of components that modeled pure business concepts that we knew could be applied in other business processes. By keeping these objects clean, and cleanly seperated from the rest of the code, they could be transplanted quite readily into other Java applications. It was at this point that I finally reaslised that enterprise architecture could be - and should be - an evolutionary design process where we discover reusable assets as we build specific applications to satisfy specific, pressing needs, rather than specify what might be needed up front with no particular application in mind.

So, the moral of this story is that you domain model is an asset, and you must work to maintain the value of that asset.
Posted 14 years, 8 months ago on January 10, 2007