Although I traditionally followed the by-layer rule just because everyone else did it, this was because I didn’t understand the potential of using package-private (i.e. didn’t know Java). Instead we tended to use Maven multi-module projects to seperate layers. These give you an extra bonus of enforcing directional dependencies between modules (don’t access the web layer from the dao, etc). But it seems that people have become lazy with the use of traditional moduling with packages..

I recently added a new piece of functionality to our project. The use case was evaluating an organization number to decide what sort of insurances your company can buy online. I started off by making a new service, EvaluationService. I put it in its own package called ‘evaluation’. I introduced a domain object called CustomerEvaluation (the result of doing an evaluation with the service), which I placed in our ‘domain’ package (by layer), but I would’ve rather put it in the ‘evaluation’ package (by feature). We still put all our exceptions in an ‘exceptions’ package, btw. These conventions are more for traditional reasons than for any good reason.

Anyway, I then implemented the EvaluationService with lots of underlying bits and pieces like IndustryCodeService, LegacyCodeTranslator and so on, all of which I dumped into the ‘evaluation’ package and made them package-private because they were just details needed to get the EvaluationService working. The evaluation package now feels really clean. It has its own Spring-context, its own nice set of tests, and one single public API exposed in the EvaluationService (and the CustomerEvaluation object).

If another piece of functionality ever needs the IndustryCodeService, I’ll probably drag it out of the ‘evaluation’ package, make it public and create an ‘industry-code’ package that both existing packages can depend on.

If it became necessary to enforce that the industry-code package would not create circular references by depending ‘evaluation’ or another, I would move it into another maven module (project) higher up in the dependency hierarchy. This would be seperating layers for the reason of enforcing good design, I suppose.

Classes could still be in the same package while being in different projects/modules.. Haven’t played around too much with that approach but it feels like it has potential. Wow, long comment better quit my rambling now. Feature package +1 :)

Although I traditionally followed the by-layer rule just because everyone else did it, this was because I didn't understand the potential of using package-private (i.e. didn't know Java). Instead we tended to use Maven multi-module projects to seperate layers. These give you an extra bonus of enforcing directional dependencies between modules (don't access the web layer from the dao, etc). But it seems that people have become lazy with the use of traditional moduling with packages..

I recently added a new piece of functionality to our project. The use case was evaluating an organization number to decide what sort of insurances your company can buy online. I started off by making a new service, EvaluationService. I put it in its own package called 'evaluation'. I introduced a domain object called CustomerEvaluation (the result of doing an evaluation with the service), which I placed in our 'domain' package (by layer), but I would've rather put it in the 'evaluation' package (by feature). We still put all our exceptions in an 'exceptions' package, btw. These conventions are more for traditional reasons than for any good reason.

Anyway, I then implemented the EvaluationService with lots of underlying bits and pieces like IndustryCodeService, LegacyCodeTranslator and so on, all of which I dumped into the 'evaluation' package and made them package-private because they were just details needed to get the EvaluationService working. The evaluation package now feels really clean. It has its own Spring-context, its own nice set of tests, and one single public API exposed in the EvaluationService (and the CustomerEvaluation object).

If another piece of functionality ever needs the IndustryCodeService, I'll probably drag it out of the 'evaluation' package, make it public and create an 'industry-code' package that both existing packages can depend on.

If it became necessary to enforce that the industry-code package would not create circular references by depending 'evaluation' or another, I would move it into another maven module (project) higher up in the dependency hierarchy. This would be seperating layers for the reason of enforcing good design, I suppose.

Classes could still be in the same package while being in different projects/modules.. Haven't played around too much with that approach but it feels like it has potential. Wow, long comment better quit my rambling now. Feature package +1 :)

The same goes of course for wrappers, adapters, bridges, and whatever: if you don’t know why you’re writing them, then don’t write them, or think a bit harder about why you’re really writing them. I think names like «util» and «common» are more a sign og laziness than anything else.

I think the most valuable point is that being dogmatic either way (like the original article) is a bad thing. Like Thomas says: “There are no ‘best practices’, only good ones”.

But I find Espen’s comment about not having enough information to create the structure in an agile project to be puzzling. I find I can organize user stories in rough features. Isn’t this sufficient?

Does anyone else have experience on finding feature categories for your code?

The same goes of course for wrappers, adapters, bridges, and whatever: if you don't know why you're writing them, then don't write them, or think a bit harder about why you're really writing them. I think names like «util» and «common» are more a sign og laziness than anything else.

I think the most valuable point is that being dogmatic either way (like the original article) is a bad thing. Like Thomas says: “There are no 'best practices', only good ones”.

But I find Espen's comment about not having enough information to create the structure in an agile project to be puzzling. I find I can organize user stories in rough features. Isn't this sufficient?

Does anyone else have experience on finding feature categories for your code?