33

I might have a silly question about DDD: Are there any disadvatages of DDD generraly? I mean, besides of using it when it is not necessary, or needed. (e.g. small/not complex projets)

Thanks

Peter
  • 331
  • 1
  • 3
  • 3
  • 2
    Small project, where applying DDD isn't worthing. @DOK So the main disadvantage is the high cost. – Peter Mar 02 '11 at 13:59
  • 1
    I would see high cost as a disadvantage it it doesn't buy you some kind of benefit. A superior outcome in the form of a high-quality application might justify the higher cost. As I see it, the higher cost occurs not only during development, but also over the application's lifetime, as it will require that everyone who maintains the application understand the design as well. – DOK Mar 04 '11 at 14:22
  • 3
    I find DDD sometimes results in more work. I am also not convinced about the concept. I mean, in my opinion, there does not need to be a coherence between a domain expert and the coder. My xp is that if I do the talking to the clients and analyse their needs, my application is more than clear enough, more than logic enough and equally as user-friendly and easy to grasp and use as when I code it in DDD. DDD does have a few interesting concepts which made me rethink stuff I 've been doing in a certain way, but I feel the 3-tier model combined with certain DDD concepts yields way less work. – Lawrence Jun 16 '14 at 21:34
  • 1
    Eric Evans charging more than $4,000 a head per DDD learning session is one indicator that it may be a convoluted practice – Andy Ray Jun 24 '21 at 20:21
  • 1
    Agree on ceremony and cost but I think another common mistake is to assume that the mental representation of the customer = optimal code model. DDD enforces overly literal translations that don't benefit from abstraction. Code also feels like government contracting - you end up with lots of 15 line classes representing an int. – Darren Nov 28 '21 at 18:40

5 Answers5

31

It is very easy to do it wrong.

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
24

Eric Evans has said in a JavaOne presentation that DDD is best applicable when there is a lot of business domain complexity. Moreover, he explicitly states that DDD is not suitable for problems where the is substantial technical complexity but that has little business domain complexity. An example of the later is an embedded system with very simple inputs (possibly independent of the number of states it possesses) while simultaneously presenting a lot of technical complexity (in terms of getting the hardware to work.)

How we go about quantifying a lot or a little, that's an open subject. But the narrative should work as a guideline of when and where DDD is best applicable.

-- edit --

I got the video presentation through Emule, and I've never been able to find that same lecture on youtube or similar video venues.

luis.espinal
  • 10,331
  • 6
  • 39
  • 55
20

I found this discussion of DDD in the Microsoft Application Architecture Guide to be helpful in understanding the challenges of that particular style:

As the core of the software is the domain model, which is a direct projection of this shared language, it allows the team to quickly find gaps in the software by analyzing the language around it. The creation of a common language is not merely an exercise in accepting information from the domain experts and applying it. Quite often, communication problems within development teams are due not only to misunderstanding the language of the domain, but also due to the fact that the domain's language is itself ambiguous. The Domain Driven Design process holds the goal not only of implementing the language being used, but also improving and refining the language of the domain. This in turn benefits the software being built, since the model is a direct projection of the domain language.

In order to help maintain the model as a pure and helpful language construct, you must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on Domain Driven Design can come at a relatively high cost. While Domain Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

DOK
  • 32,337
  • 7
  • 60
  • 92
11

At an italian conference, I talked about the topic (see these slides).

DDD projects require domain experts that are often expensive to hire, since they hold valuable knowledge (read, if you don't need a domain expert, you don't need DDD).
Moreover DDD requires strong skills on the modeler side. In particular they have to be:

  1. Humble, since they have to accept their ignorance and learn from an expert
  2. Really skilled in OOP
  3. Diligent, since they have to track decisions
  4. Comunicative, since they have to explain the domain to the other devs (even through documentation)

Finding such developers can be much more expensive than expected, since you can really know that they are good at the job after some months of trials.

Giacomo Tesio
  • 7,144
  • 3
  • 31
  • 48
2

Martin Fowler in his "PoEA" book has a great discussion of when and what domain logic patterns to use.

For instance, simplest pattern, Transaction Script, involves no domain model.

Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91