There are three core concepts in domain driven design, they are aggregate root, entity, and value object. An aggregate root is something that has an identity in the model. This is different than an entity which is just something that has an identity.
What is the difference between an aggregate root and an entity? In this webinar’s online shop example, we are going to have an Order and an OrderLines. Both of them are going to be entities. I can say, “Give me OrderLines 6, or give me Order 50.” This is, if I am using a relational database, because effectively I must have a primary key on the OrderLines table.
On the other hand, in my model, I am never going to say, “Give me OrderLines 5.” It doesn’t make sense. In my model, I am always going to approach an OrderLine within the scope of its own parent order.
In the book, Domain Driven Design, by Eric Evans, he talks about only creating references between aggregate roots, even if you have entities that are encompassed by single aggregate root you should only have one of them.
With RavenDB, the situation is different. We don’t actually have the concept of an entity. To be more exact, the division that we typically do is that we have a document, and a document is a 1 to 1 mapping to an object graph that is an entity inside your application.
Modeling three rules of thumb
For modeling in RavenDB, here are three rules of thumb for each document:
- Independent: A document should have its own separate existence from any other documents. You can take a document and do stuff to it, without having to do stuff to anything else. A document is not independent if it can’t exist on its own. An OrderLine document is a good example of a document that is not independent. An OrderLine document will always exist within an Order, it’s right there in the name.
- Isolated: A document can change independently from other documents. A document is not isolated if every time that I modify a document, I also have to modify a different document.
- Coherent: A document should be legible on its own, without referencing other documents. A document is not coherent if, in order to understand it, I have to reference another document. A good example is an association table in a relational database. It’s meaningless unless you join to the other tables that it relates to.
You want to get to a point where you can look at the document, you can make sense of it, you can modify it on its own without touching anything else, and it doesn’t break any part of the system.
Skip to Navigation
