Domain Driven Design for C# 3.0

Or maybe 4.0? Paul Gielens got my brain jump started this morning with a post about DDD support in the C# language. Domain Driven Design can be hard to grasp and even harder to implement. Conceptually it's easy and makes sense (at least to me). We all read the books and get the theory, but when the rubber hits the road the biggest question anyone has is "how do I write code that reflects this?". Everyone has ideas and if you take a quick search of the DDD mailing list, you'll see dozens of code snippets all talking about the same thing but implementing it differently. Sure, software development and pattern is like that. Take any one pattern and give it to 3 people and you'll get 5 different interpretations. However as we continue to dance around implementation, we get confused by the terms and sometimes miss the ball.

Here's a DDD type implementation using C# constructs so the intent isn't all that clear here:

    1 namespace Car

    2 {

    3     class Wheel { ... }

    4     class Position { ... }

    5     class CarRepository { ... }

    6     class FuelTransfer { ... }

    7 }

Now given the spark that Paul mentioned, here's the same code written in DDD style:

    9 domain Transportation

   10 {

   11     aggregate Car

   12     {

   13         entity Wheel { ... }

   14         valueobject Position { ... }

   15         repository CarRepository { ... }

   16         service FuelTransfer { ... }

   17     }

   18 }

If you've read DDD and internalized Eric Evans' theory around things like aggregates, boundaries, entity and value objects you'll get this. You'll see the domain visually (or at least I do) and understand it. No longer would you have questions like "is x an aggregate of y and where should service z live?". The code tells all. Brilliant.

I love C# but it does have its limitations in that it's just simply regurgitating the language it was based on and has typical constructs like class, namespace, etc. I'm sure (but haven't thought how you could do it) that say a language like maybe Ruby could support this but that's an answer for those smart types like John Lam to answer (although with John at the mothership now and working on the CLR team, anything is possible).

I think it's an excellent idea, my only wish is that something like this could come true someday!


  • Hi,

    Nice to see something like this. This seems like a DSL on top, or extending the CLR infraestructure, this could be really cool for other kinds of domains too.


  • What do you think about attributes for decorating the classes? Values of the attributes could be entity, valueobject etc.

    I don't follow the discussion on the mailing list so my idea might have been discussed there before.


  • I don't really know anything about DDD, but such a DSL would be trivial to implement in Ruby.

    I really believe that DSLs are a key advantage of languages such as Ruby. Note that it's not an intrinsic advantage of dynamic languages - it's more of a case of Ruby's syntax being so malleable that it makes it easy to implement things like you described.

  • Well John, next time I'm at the mothership I'll give you 15 minutes to bone me up on Ruby and you give me 15 to get aquainted with DDD then we'll be all set ;)

Comments have been disabled for this content.