Skip to main content

About package names

By 3 juni 2014januari 30th, 2017No Comments

I once heard this story of an autistic boy who needed to pack his belongings. His parents had decided to move to a different house and he was given a few boxes to pack all his stuff laying around the house. This raised the question on how to group all the things together. When the parents came around to unpacking his stuff, it turned out he packed all the metal things with metal things, plastic things with plastic things and wooden things with wooden things.

While it is certainly a reasonably well-defined way of grouping (there will always be edge cases), it is not necessarily the most convenient. For example, grouping stuff for the destination room is a lot more efficient when moving.

The story got stuck in my head and I see the same thing happening in most if not all projects I work at. For some reason, Java developers like to put all entities in a package called ‘entities’ or ‘db’. The DAO’s of course go in a package ‘dao’ and services go in the package… ‘services’. Teams are divided in a frontend team, a middleware team and a database team.
Again, it is pretty well-defined where things need to go. But is it the most efficient?

In most cases it is pretty clear from the class itself that it is, for example, an entity. The @Entity annotation pretty much gives it away. Even if it is defined in some obscure XML file, from the facts that it has some fields with getters and setters and not much more, it should be reasonably obvious. The same goes most other common design patterns. If it isn’t clear, you’d have a different problem. In some coding style conventions, it actually is compulsory to put it in the name (e.g. PaymentEntity and PaymentDao. So putting the entities in the same package doesn’t provide any extra information.

If business wants to create, let’s say, a wizard to change a user’s address. That would involve probably all teams: the GUI team needs to do some screens, middleware needs to create logic and the DB guys need to create and change the tables. That will require a lot of communication and no single team is responsible for the full feature.

Why not use package names (or module names on a different abstraction level) around business areas. For example, all the user management stuff in a package ‘user’. That includes the entities, the dao’s and services. That way, it is immediately clear which services use which entities. Of course, there will be some shared classes which don’t fit into a single area so it immediately becomes clear that these are part of the ‘core’ system and thus needed to be treated with care. Placing them into a specific package again helps to communicate this. It also makes it easier to form teams per business area. Each team would be more or less responsible for some of the packages. It will help lower coupling between business areas and thus be more aligned with business expectations.

Or we could simply stick with the simplicity and very clear division of putting plastic with plastic, and metal with metal. That at least will probably cause less discussion. If that is a good thing, I’d like to leave as an exercise for the reader.