CODEWITHSUNDEEP
domain-driven-designravendb
AndyM
AndyM

Reputation: 1200

RavenDB Domain Model

I'm building my first small RavenDB application and I'm wondering if I'm approaching things correctly when building my domain model.

I've got a list of countries which I want to use in multiple places in my model. Typically in the past I would have created a database table to store the countries and a country object which looked a little like this:

public class Country{
    public int Id {get;set;}
    public string CountryName {get;set;}
}

When I went to use the country class I would have held an instance of it inside another object for example:

public class Shop{
    public int Id {get;set;}
    public string Name {get;set;}
    public Country InCountry {get;set;}
}

Or

public class Customer{
    public int Id {get;set;}
    public string Surname {get;set;}
    public Country CountryOfResidence {get;set;}
}

And so on and so forth. Am I correct in thinking that what I should now be doing is storing the Id of the country in the Shop and Customer classes so they would now look like this:

public class Shop{
    public int Id {get;set;}
    public string Name {get;set;}
    public int CountryId {get;set;}
}

public class Customer{
    public int Id {get;set;}
    public string Surname {get;set;}
    public int CountryOfResidenceId {get;set;}
}

When I go to pull these from the database I can then use the includes feature of the Raven API to get the related country object albeit it's in a seperate object and I can't for example do myCustomer.Country.Name.

Obviously this is a very contrived example but I really just want to check that I'm not barking up totally the wrong tree before carrying on down this route.

Upvotes: 1

Views: 488

Answers (1)

David Masters
David Masters

Reputation: 8295

I haven't properly used a document DB (yet), but my thoughts on your question are:

  • You shouldn't bend your domain model in order to fit the needs of your persistence implementation, but if there was ever an opportunity to keep your aggregate design completely persistent ignorant, I would have thought it would be when using a document database.
  • If the country object only consists of a name, then it's most likely a Value Object and doesn't even require an ID. Value objects are immutable, so if a shop's country changes you just replace the whole object. There's no need to reference an ID because it doesn't matter that multiple aggregates/entities are referencing the same value.
  • Regarding child entities: they only serve a purpose within the scope of an Aggregate, meaning you shouldn't have the same entity existing within multiple aggregates. So I would have thought, again, store the entire object and not a reference to an ID.
  • Referencing other aggregates is different. This is where you want to reference by ID. This article explains why.

Upvotes: 3

Related Questions