views:

312

answers:

1

Hello, I'm new to DDD and NHibernate.

In my current project, I have an entity Person, that contains a value object, let's say Address. Today, this is fine. But maybe one day I will have a requirement that my value object (in this case Address), will have to become an entity.

Before trying to model this on a DDD-way, in a more data-centric approach, I had a table Person, with an Id, and another table Address, whose PK was actually an FK, it was the Id of a Person (ie, a one-to-one relationship).

I've been reading that when I map a Value Object as a Component, its value will get mapped as columns on my Entity table (so, I would not have the one-to-one relationship).

My idea was that, when needed, I would simply add a surrogate key to my Address table, and then it becomes an Entity.

How should I design this using NHibernate? Should I already make my Address object an Entity?

Sorry, I don't even know if my questions are clear, I'm really lost here.

+1  A: 

In the system we are building, we put value objects in separate tables. As fare as I know, hibernate requires that a id is added to the object, but we ignore this and treat the object as a value object in the system. As you probably know, a value object is an object that you don't need to track, so we simply overlook the id in the object. This makes us freer to model the database the way we want and model the domain model the way we want.

Fossmo
the same approach here. ddd does not demand that object should not have a property called id - it just tells that value object is object without identity.
Arnis L.
Hmmm, what about creating a protected Id, so that I hide it, but NHibernate is still able to see and map it?
Bruno Reis
But you will end up with repeated entries in the value object table. How to avoid it?
Seiti
I suspect that in the absence of an identifier, NHibernate will never be able to tell if the value object is transient or persistent (is it already in the table or not?), and will always perform an additional `SELECT` query to check before inserting or updating any entity that references the value object. I have gone the route of the protected id so as to improve performance in this regard, even though it introduces a persistence concern into my otherwise clean domain object.
Jay