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.

  • I'm a little confused. Are you rejecting the authors argument? Modules/Packages/Tiers are certainly a concern of DDD and should reflect the model. Tiers (at least in this case) are bad DDD because traditional tiers are designed to split technology rather than domain. In the case of your email example, email is not an ENTITY it is a SERVICE. So the fact that Domain.Contact does not translate into the service itself should not be a problem because SERVICES have an identity of their own and should be treated as "dumb". Call the email with a facade. – P.Brian.Mackey Feb 19 '15 at 16:28
  • I thought we were talking about traditional tiers. – Robert Harvey Feb 19 '15 at 16:32
  • Maybe I did not give enough context. The author is talking about tiers in the Modules section of the book. – P.Brian.Mackey Feb 19 '15 at 16:34
  • Does the fact that this conversation is in the "modules" portion of the book matter? He's still talking about tiers, right? – Robert Harvey Feb 19 '15 at 16:35
  • Yes, tiers and modules. I didn't think it mattered, but I'm a little lost :) – P.Brian.Mackey Feb 19 '15 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.