Package structure

Package structure is not something to be considered idly.
The first thing I do when I look at an application is
$ tree -d src/
And I get something like this:

com
 --host
 |-- core
 |   |-- dao
 |   |-- domain
 |   `-- engine
 |-- service
 |   |-- business
 |   |-- adapter
 |   |-- exception

What do I know about this application from its package structure? Not much. It has a core, an engine, that's exciting. But not at all descriptive of what it does. Sounds like a spaceship! or an alien weapon!

However, if I were building a spaceship, I'd do something like this:

org
--ship
|-- lifesupport
|  |-- atmosphere
|  |-- gravity
|  |-- replicator
|-- communications
|-- propulsion
|  |-- thruster
|  |-- impulse
|  |-- warp
|-- defense
|  |-- shield
|-- weapons
|  |-- phaser
|  |-- torpedo

OK, so a space ship is much much easier to design than a piece of software! I have all the major features described at the top level. I can tell what the ship does, what its major components are.
The ship's design is organized by Features of the ship. Not by layer or any other attribute. For example, a builder or a command isn't a feature of a piece of software. Neither is an exception, a dao, a domain, an adapter..
These are all layers or programmatic idioms. Grouping classes by layer or type is a common mistake in designing software. It is always taught that one should design by feature, not by implementation detail.