Building of your Domain Objects?

Question

I'm in the process of trying to learn Domain Driven design so i'm sure this will be the first of many questions (i can already think of at least a couple more but i don't want to fragment my questions). I'm using Dino Esposito's "Architecting Microsoft .NET Solutions for the Enterprise" which, in some cases, is very abstract.

First of all, i always assumed your business objects would have some type of connectivity (passed in through the constructor) whether it be a repository or DBConnection or whatever. Looks like i'm wrong.

Do you just construct your domain object by a combination passing in ALL the data and maybe some add/remove functions for the underlying collections (Order-->OrderDetails)? So in your DataMapper you would construct the buisness objects from the tuples in your DB and then return them to an application layer through a repository where you would use them? Then both your application layer & DL would need a reference to your Business objects. This would of course force you to build in your own lazy loading mechanism if your not using an ORM or maybe even if your using an ORM because you would be disconnected at this point. You wouldn't want to load ALL the underlying data in all circumstances of course.

Answer 1

According to domain driven design - domain objects are persistence ignorant. That means - they shouldn't contain infrastructure code that connects to database. However - repository abstractions are considered as part of domain model. Therefore - it's 'allowed' to use those, but I personally like to avoid that.

If You are talking about modeling of domain objects - then no, mostly it's not a good thing to model them as dumb data bags. That leads to anemic model.

If You are talking about reconstructing domain objects when they are retrieved from persistence mechanisms, then Yes - basically that's just rebuilding domain object from scratch. But tricky part here is - this rebuilding and other persistence related issues should not invade into Your domain. You should not have public add/remove functions without any validations just to make Your persistence to work. In reality - it's hard to keep model completely clean (in fact, it's already messed up with programming language You are using and there does not exist pure medium that could hold it, apart from reality You are modeling itself) and there will always be some implicit dependencies (e.g. - everything must be marked virtual when using NHibernate ORM).

But You aren't focusing on what You should in case You want to understand domain driven design. Core of domain driven design is ubiquitousness in language and explicitly modeled business. It's about way You think. Start with reading 'blue book'. Twice. And check out this sample application by Szymon Pobiega until You understand reason behind those lines of code.

EDIT: Oh... forgot about ddd yahoo group which is quite nice source of info too.

---

One thing that confuses me in your post is about you shouldn't "Model" them as dumb property bags but in "reconstructing" then its ok.

Take a look at this (oversimplified and bad one) example. From client side, unless You are cheating, You won't be able to create a new Person that has name.Length>50.

public class Person{
  public Person(string name){ 
      if (name.Length>50) throw new ArgumentException
        ("Person name length should not exceed 50 characters");  
      Name=name;
    }
    public string Name {get;private set;}
}

But when we reconstruct object from persistence mechanisms - cheating is exactly what we do. We bypass validation, we set data directly, we bypass object behavior because data is what represents state. E.g. using reflection:

typeof(Partner).GetProperty("Name").SetValue(partner,nameFromDB);

---

It sounds like its a very complex topic and probably a lot of people who think the are using domain-driven design..aren't

Domain driven design at start is truly confusing. And worst thing what could happen (and usually happens) is when developer starts to believe out of nowhere that he is doing it right (been there myself. might be I'm still there):

And... is the Domain-Driven Design used in .NET pop culture really Domain-Driven Design in fact

That leads to lot of confusion and falsehood. Some try to explain why. Some just hate it.