Implementing Domain Driven Design

Is anyone using the techniques from Domain Driven Design? I've recently read the Eric Evans book of the same name (well, most of it!) and would be interested to hear from anyone who's implemented all/some of it in a project (particularly in C#/C++)

I've kept this question open ended as I'd like to see as many comments as possible, but I have a few questions in particular:

1 - Should value types be real 'value types' if the language supports it? e.g. a struct in C#

2- Is there any feature in C# that makes clearer the association between the language and the model (for instance, this is an entity, this is a开发者_如何学Gon aggregate etc.)

---

Yes! I use DDD in my projects (but I'm biased!)

Remember that Domain Driven Design provides guidelines, not strict answers. It's only after experimenting that you'll understand which aspects work for your specific project.

Onto your questions:

1 - You could use structs - but there may be technical constraints that prevent you using them. For example, you may have entities that references thousands of value objects that happen to have the same values. In this case, it might be better to use a flyweight object to keep memory usage down.

2 - I would suggest using interfaces (e.g. IEntity, IValueObject, IAggregateRoot, ISpecification). Generics and LINQ can help assist in the technical concerns, but are less helpful from a design perspective.

I've created a [free .NET library][2] specifically focused on DDD, which might find ideas/inspiration from. [Read more about it here.][3] (project is dead)

I'm genuinely interested though: Which aspects of DDD do you think will benefit you? The "Domain Driven" aspects, or the implementation aspects?

---

1: depends. Value types in C# are for atomic pimitives (int, byte etc.). If you have something like that - it makes sense. If your value type is larger, no.

2: No. In general this is not a language feature.

I suggest as next read: Scott Ambler's "Building Object Applications That Work".

---

1 - Should value types be real 'value types' if the language supports it?

I think the answer to that will depend on usage and other factors within your application, but the pattern you're probably looking for is "Data Transfer Object" which has properties, getters, and setters, but nothing else. It can be either a struct or an object, and objects will probably simplify memory management issues, especially with regard to boxing.

2- Is there any feature in C# that makes clearer the association between the language and the model (for instance, this is an entity, this is an aggregate etc.)

I would go with naming conventions, e.g., "CustomerEntity", "OrderAggregate", etc.

Good question; I'm looking forward to seeing responses.

---

1 - Should value types be real 'value types' if the language supports it? e.g. a struct in C#

Don't get confused between the DDD notion of "Value Object" and the CLR notion of "Value Type" (structs in C#). The former has to do with design, and the latter is a lower-level implementation consideration that really has more to do with memory management than anything else.

2 - Is there any feature in C# that makes clearer the association between the language and the model (for instance, this is an entity, this is an aggregate etc.)

When tackling entities vs. values, yes. We've found that using readonly in C# is very helpful for implementing Value Objects in DDD. We're embracing DDD in a big way at Pluralsight, and I blog about it from time to time on the Pluralsight blog. Indeed I've scheduled two blog entries about readonly and DDD to go out later this week.

[1] http://blog.pluralsight.com/tag/ddd/