In Eric Evans book on DDD in the Modules section he says,
[tiered design] is attempting to address two legitimate issues. One is the logical division of concerns: One object has responsibility for database access, another for business logic, etc. This makes it easier to understand the functioning of each tier (on a technical level) and makes it easier to switch out layers. The trouble is that the cost to application development is not recognized. This is not a book on framework design, so I won’t go into alternative solutions to that problem, but they do exist. And even if there were no options, it would be better to trade this off for a more cohesive domain layer.
The other motivation for these packaging schemes is the distribution of tiers. This could be a strong argument if the code actually gets deployed on different servers. Usually it does not. The flexibility is sought just in case it is needed. On a project that hopes to get leverage from MODEL-DRIVEN DESIGN, this sacrifice is too great.
Can you give an example of an alternative solution to tiered applications that is DDD friendly?