CODEWITHSUNDEEP
domain-driven-design
Peter
Peter

Reputation: 341

Domain Driven Design disadvantages?

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

Upvotes: 34

Views: 15975

Answers (5)

Giacomo Tesio
Giacomo Tesio

Reputation: 7210

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.

Upvotes: 11

luis.espinal
luis.espinal

Reputation: 10519

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.

Upvotes: 24

smartcaveman
smartcaveman

Reputation: 42246

It is very easy to do it wrong.

Upvotes: 32

Victor Sergienko
Victor Sergienko

Reputation: 13475

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.

Upvotes: 2

DOK
DOK

Reputation: 32831

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.

Upvotes: 20

Related Questions