I stumbled upon Greg Young's talk 7 Reasons why DDD Projects Fail where he mentions something he calls DDD-Lite at 7:20.

Summarizing, he basically says some use DDD as a pattern languages (entities, repositories, value objects, services, etc) without doing anything else related to DDD. He postulates 60% or more of domain models in .Net are DDD-Lite. He thinks DDD-Lite is basically building up a language around dependency injection, something you don't really need to do. He says either do DDD entirely or do something simpler. Otherwise he claims a person is putting forth all of this work in building good abstractions, but without any real benefits.

I must admit I don't know as much about DDD as I would like, and have not tried to use it yet. I also haven't read Eric Evan's book either. I am much more interested in Dependency Injection and many, many books and blogs on this subject use terms and reference concepts from Eric Evans' DDD book. This is where I've been exposed to DDD concepts. Books I've been reading that do this include:

  • Dependency Injection in .NET
  • Microsoft .Net: Architecting Applications for the Enterprise
  • Brownfield Application Development in .NET

If one wants to do Dependency Injection, what are simpler alternatives over doing "DDD-Lite?" It sounds like to me building good abstractions are quite useful regardless of if one is using concepts from DDD in a "DDD-Lite" way. (see Mark Seemann's blog posts: Interfaces are not abstractions, and Towards better abstractions). I have a hard time believing everyone doing Dependency Injection happens to also be doing (or needs to do) full fledged DDD. Did I somehow misunderstood Greg Young's argument about DDD-Lite?

2 Answers 2


Dependency Injection and DDD are two disjoint concepts. Doing Dependency Injection does not require to do DDD nor does DDD require Dependency Injection.

A lot of DDD projects fail because they pick the patterns but neglect the process behind DDD. They do not take the time to extract business rules. They do not concentrate on the domain model and on careful abstractions. They don't establish an Ubiquitous Language.

In short: I guess that's a misunderstanding

  • 4
    +1 The patterns described in Evans' book are still valuable in a much broader context - as long as one understands that applying them in isolation doesn't make it DDD. Commented Nov 8, 2011 at 20:48
  • 1
    Yes I realize DI != DDD. @MarkSeemann, so Greg's argument seems to be that people are saying they are doing DDD when they aren't. Okay I get that. But he also argues that using abstractions like found in DDD (aggregates, repositories, domain entities, value objects, services, etc) are unnecessary if those are being used just to support a dependency injected architecture. That's the part I don't get (what wrong with it). Perhaps such is straw man argument, as using such things aren't just to "build up a language around dependency injection".
    – Matt
    Commented Nov 8, 2011 at 21:51
  • 3
    Greg is partially correct: the special patterns in DDD aren't particularly related to DI. However, in my book I picked up some of the terminology, particularly the definition of Entity vs. Value Object vs. Service because it's important to understand what to inject where. However, both this terminology as well as other patterns like Repository and Factory are much older than the DDD book, so saying that such things are unnecessary outside of DDD sounds incorrect to me. It may depend on how you actually define DDD. Commented Nov 9, 2011 at 8:07

I bet Greg is referring to the simple application if a subset of Domain-Driven Design patterns instead of the whole DDD approach. The term DDD-Lite implicitly refers to the book http://www.infoq.com/minibooks/domain-driven-design-quickly that used to be popular among DDD newbies, but sot of misses the whole picture by focusing only on the local modeling design patterns.

Though Dependency Injection is considered a good thing, there is no strong correlation between DDD and DI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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