[ACCEPTED]-Domain Driven Design disadvantages?-domain-driven-design

It is very easy to do it wrong.

0

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

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

-- edit --

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

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

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

In 8 order to help maintain the model as a 7 pure and helpful language construct, you 6 must typically implement a great deal 5 of isolation and encapsulation within 4 the domain model. Consequently, a system 3 based on Domain Driven Design can come 2 at a relatively high cost. While Domain Driven Design provides many 1 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.

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

DDD projects require 9 domain experts that are often expensive 8 to hire, since they hold valuable knowledge 7 (read, if you don't need a domain expert, you 6 don't need DDD).
Moreover DDD requires strong 5 skills on the modeler side. In particular 4 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 3 can be much more expensive than expected, since 2 you can really know that they are good at 1 the job after some months of trials.

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

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