Modules With Meaning

Traditional module structures reflect the design of applications. For example domain, action or command are module names I commonly notice when casting an eye over a codebase.

For applications with fair amounts of functionality this type of structure leads to very crowded packages. Designs are usually fairly easy to grasp as it is, a short conversation is usually adequate to grasp the bulk of a design. Alternatively, work on a card touching all application layers and you’ll usually get the gist of it. Furthermore, from my experience each application type tends to have it own design blueprint; Web Apps are designed a standard way, Swing Apps another way, etc. So the value in communicating the design of an application via it’s modules is fairly minimal.

I tend to subscribe to Eric Evans’ approach to module design, I find it much more useful to have a module structure communicating the domain of the problem being solved. While the benefits of communicating and reinforcing a ubiquitous domain language are significant it also has little benefits like encouraging modules to have much less citizens.

It’s hard to break with tradition at the best of times without having seen theory work in practice. So I’m not surprised to see that my latest project has a monolithic module structure even though there’s been a few people on the project who’ve read Domain Driven Design.

Unfortunately it’s also common place to define so-called ‘domain models’ that are void of behaviour. Surely this is a bastardization of the term ‘domain model’, but if it’s your cup of tea then why not consider persistence via Entity Beans ;-).