Domain Driven Design - how relevant is it in a Technical Domain?

Question

This is one thing that has been bugging me for a while about DDD. I can clearly see the benefits of the approach when dealing with non-technical business domains with complex models and lots of interaction required between technical people and non-technical domain experts.

However, what about when the 'domain' in question is technical?

For instance, situation A) take a web start-up. Imagine they are trying to accomplish something quite complicated (say a facebook clone), but almost all of the staff are technical (or at least have strong technical understanding).

What about situation B) A similar situation, but with a slightly less ambitious project, and a lone developer trying to create somthing with an elegant architecture.

I'd be really interested to hear what people have to say. What I'm really trying to get to the meat of, is where the benefits of DDD lie, what the downsides might are, and at what point one outweighs the other...

Answer 1

DDD is really just an elaboration of the design pattern Fowler calls Domain Model in Patterns of Enterprise Application Architecture. In that book, he compares Domain Model to other ways of organizing code, such as Transaction Script, but it is clear that he prefers Domain Model over other alternatives for all but the simplest of applications. I do, too.

DDD simply expands greatly on the original concept of a Domain Model and provides tons of guidance on how we should analyze and model our domain in a way that will be beneficial to ourselves as developers.

If the Domain in question is complex, then a Domain model (and hence DDD) is a good choice. It doesn't really matter whether the Domain is business-oriented or more technical in nature. In his book Domain-Driven Design, Eric Evans starts by describing how the DDD techniques helped him model a Printed Circuit Board application. That is surely a technical Domain, if any!

In my current work, we are using DDD to model an application that deals with Claims-based identity - another very technical Domain.

DDD is really just about dealing with complexity in sofware, and this is also the subtitle of Evans' book: "Tackling Complexity in the Heart of Software."

Answer 2

Evans suggest using Domain Driven Design when :

Domain Complexity > Technical Complexity

• If your domain is simple but you have many technical limitations (technology choice, performance restrictions etc), do not use DDD.
• If your domain in complex, do DDD, put the domain as the core of your system, and move any other concern outside (persistence, performance, technology concerns).

Answer 3

I don't really have a great answer for you, but I can say from my perspective as an outsider to DDD with an interest in DDD I've seen technical domain concepts / drivers creep into the the DDD conversation as first class concepts. A good example of this would be that some people are advocating for technical / infrastructure bounded contexts. The best example I can think of is Greg Young's architecture where he considers reads a bounded context and transactional writes another bounded context. In general I think things like this are "domain constructs" (my term... forgive me if I must mutilated a real DDD term). It's similiar to objects in the OO world that don't model something in the real world but are fully flushed out objects.