An ill fitting domain model is a blight upon your application. Sharing the most personal part of your application can stretch it out into a floppy mess that isn’t fit for any system.
The domain layer of your application embodies the problem being solved. In the world of software high fashion, the domain layer should fit the problem like a well tailored suit – snug but comfortable with room to move.
Quite often another problem comes along that appears to be the same as one you’ve solved already. They look to be of similar build and height so getting some more wear out of those expensive duds seems to make good sense. Unfortunately, on closer inspection things don’t fit that well; the shoulders are loose and the stomach is tight. One false move and the seat of those slacks could be rendered asunder.
The domain can be let out to accommodate both systems but it will never fit as well as if it was tailored for a single purpose. As the shape of each system changes over time (middle age spread affects software as well), subsequent adjustments will become harder because of the need to satisfy both parties. Try to stretch the domain across multiple systems and it will pretty soon begin to look like a muumuu.
So what if the domain is a little baggy in the arse? Aesthetics aside, a poorly fitting domain is a strong contributor to software entropy (disorder).
The domain code of your application should sufficiently explain the problem your application is trying to solve. The domain code records the interpretation of the problem formed by the original developer. Subsequent developers will use this recording to form their own mental model of the problem and make changes to the code in turn. The domain code becomes an essential tool for communicating the original problem to new developers.
Problems occur when the domain code does not accurately model the domain. A poor model of the domain in code will lead to a flawed mental model being formed by any new developer. Changes contributed using this incomplete or inaccurate understanding further reduce the fidelity of the domain code. If the decay is left unchecked then the model can eventually lose all shape. New additions will be tacked on awkwardly and the domain will mutate out of control. The mutation will increase exponentially and eventually the system will need a total rewrite simply because nobody can understand it any more. The sad situation is that the rewritten system is often doomed to the same fate, it just starts off in a less advanced stage of decay.
So what can you do to keep your domain layer looking snappy?
Preserve the cut of your domain. Don’t stretch it out of shape by attempting to make it an all singing all dancing representation of multiple problems. Two different systems may utilise the same data but be concerned with separate behaviours – if this is the case then consider modelling two separate domains.
Realise that some duplication is worth it or is not really duplication at all. Just because two entities have the same properties they don’t necessarily model the same thing. Don’t strive for reducing code duplication at the cost of clarity.
Periodically update your application’s wardrobe. Review the problem domain and make sure it is still accurately modelled in the code. Always remember that the domain code is there to communicate the problem to others. Invest the time to improve it continually and don’t be afraid to make changes if the model is no longer accurate.
Make your domain code easy to understand by keeping it simple. Use techniques such as TDD to drive your code to be barely sufficient and easier to digest. Use an evolving domain model instead of a big up front design based on guesswork and incomplete understanding. Don’t add a bunch of crap that you think you’ll need – add it when you need it. Chime in obnoxiously with “YAGNI!” whenever anyone else suggests otherwise.
Keep to the boundaries of the problem you are trying to model. Sure there may be things attached at the perimeter but resist the temptation to try and capture everything; just focus on the view that affects your application. Limiting this view makes it easier to comprehend.
Finally, remember to just say no to the false economy of domain code reuse. Domain code should be something intimate to your application and the problem it is trying to solve so keep it that way. Compromising the quality of your domain code will lessen the ability of your application to communicate the problem domain to others and will accelerate the decay of your system.
fuglylogic 