DISQUS

As to the original request of your blog post: "stand up and be counted:" You'll have to count me twice.

We implement a proprietary technology stack in-house, this code is packaged by layer. Services / features running on top of that however are packaged by "service" as much as possible... except for some small util bits which I can't be bothered to put in their own projects. ;)

I guess I really just have trouble with the either-or tone of the referenced article. There are no "best practices", only good ones in a given situation.

Let's say both "product" and "order" use the same bit of util code for authorization before running any given function?

I suppose I was thinking about crosscutting concerns/"infrastructure code" here, not domain logic. I'm having trouble coming up with a domain class that can't be its own feature. :)

Anyway. Unless everything in the project problem space is covered exactly by a specific function call to some external library or service - where do I put things like util classes, wrappers, adapters, bridge code ...?

If package-by-layer is completely verboten (like the tone of the article implies, e.g no com.app.util package), then doesn't it follow that every bit of util/infrastructure code (which is used by more than one feature) will have to go into a separate library - giving me more cruft to worry about in my build environment etc?

From the article:
"Let's see. I wonder where this item is located....Oh, here it is. And everything else I am going to need is right here too, all in the same spot. Excellent."

I wonder; where in the package structure does the author of the article propose I put domain classes/functions which are used by more than one feature? :)

*Voted*
Checked exceptions = one of the more annoying java quirks after I got back into other languages on a daily basis. "Why do I have to deal with this crap?"