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?
Tiers and DDD are orthogonal concerns.
Your tiers shouldn’t care about the design of your objects. That would imply tight coupling, an undesirable attribute. In most tiered systems, there is some sort of data transfer object or data stream that is communicating information between the tiers. XML and JSON are common. Each tier has its own objects it concerns itself with, and is not particularly concerned about some other tier’s object design.
If you doubt this, then consider how DDD friendly your email server is. While your email server does have a concept of what a “contact” is, it’s highly likely that it’s not exactly the same object as it is in your CRM system. There are software mechanisms that can “sync” between email servers and CRM systems using the Adapter pattern, but it’s not true blue DDD by any means.
6