Recently, my friend and colleague asked some questions about package naming conventions in Grails. I think they were excellent questions, and I wouldn’t be surprised if others were wondering about the same things. You could get into arguments over stuff like this, but here is my perspective.
Q: Is there an inherent advantage to using a package naming convention like com.businessname.appname? Do you use this by default, or does it vary according to certain designs?
This is pretty standard, and a lot of Java EE shops do it this way. There is nothing forcing you, however, but I think this is the right way.
Let’s say your company is WidgetCo Inc, and they have a website at www.widgetco.com. They want a new webapp called “Spanky” that will allow online ordering:
com.widgetco.spanky
This package structure will allow them to easily create another webapp in the future for their internal payroll (or whatever):
com.widgetco.payroll
So com.widgetco is their company package, under which they can organize all their applications.
Q: I saw a post on the Grails mailing list about someone having package names like com.businessname.appname.domain and com.businessname.appname.controller. Does adding “domain” or “controller” have an advantage? It seems like it would prevent name clashes, but it also feels like overkill.
Don’t do this! This is bad practice. Grails creates these separations for you within the grails-app directory structure by having separate controllers/, domain/, services/, and jobs/ directories.
The point of this is that you can have your Foo domain object, FooController, FooService, FooJob, and FooTests all in the same convenient package. When people start putting .domain, .controller, or .service in their package names, they ruin that cohesion. Now, you have to write lots of meaningless import statements.
I once worked with a client that kept all their domain objects in a .domain package. Every time I worked on their codebase, I spent half my time dealing with redundant imports. If you are inside FooController and you have to explicitly import the Foo domain class just because it is in a different package, that is a design smell. Repackaging is a huge pain in the ass once a codebase grows, so it is critical to get your packaging right early.
Rule of Thumb: Package names should describe and separate code functionality, not code type.
The .domain package describes the type of code within (domain classes). This is a bad idea because Grails already provides separation of concerns at the folder level.
The right reason to create a sub-package is because you have some specific code functionality that spreads across your application. For example, say you have written a custom rules engine. You might keep the core class in:
/src/groovy/com/company/app/rules/RulesEngine.groovy
If it has an associated Rule domain object, that goes in:
/grails-app/domain/com/company/app/rules/Rule.groovy
And a rules-related service goes in:
/grails-app/services/com/company/app/rules/RuleService.groovy
By keeping them under the com.company.app.rules package, they are logically grouped together by functionality, not by code type.
Q: I assume that it’s in the best interest of devs to decide on a package naming convention earlier rather than later.
Absolutely. The best time to start packaging a Grails app is right after you create your first domain class. Once you have a paradigm set for your application, making new classes conform to it is simple. Applying a package structure as an afterthought can be incredibly tedious.
Don’t feel bad if you’ve seen variations—I’ve seen plenty of enterprise Java teams do counter-intuitive things with package naming. Get the conventions aligned early, keep it functional, and let Grails handle the rest.