0

Is uniqueness considered a persistence concern in DDD?

The reason I ask is because I have a Customer object in an order quoting context. e.g. an order is for a customer and the customer must pay a certain rate.

Technically, I won't allow a customer to have the same code or name as another. Which means if I have two Customer objects with the same code and name, they'll always be treated the same like a value object.

But instinctively, a Customer feels like an entity. Is the unique constraint throwing me off, or am I right to think it's a value object?

The order quoting context will also allow customers to be added/edited/removed from an admin page. Could the confusion be caused by this? Should admin pages be part of another context where Customer is an entity, and the order quoting context will use Customer as a value object?

peefartpoop
  • 133
  • 1
  • 7

1 Answers1

0

This is an excellent question, and you partially answered it already, your Customer is an Entity in your bounded context of administration.

A good rule of thumb to decide whether or not an object is an entity is to think with the concept of identity. If your object require an identity which will stay the same as the time flies, even if the person's name or contact details can change then its likely an Entity.

However, with that concept defined, you can have a CustomerId, which is composed of the invariant from a business point of view, in your case the code and name.

This CustomerId is not a technical ID, its a business ID, and your entity's identity will be this ID. In the Order quoting bounded context, you can then reference your Customer using this same object (probably defined somewhere in a shared context, or by duplicating the code: its ok in DDD to duplicate some code to promote loose coupling).

Sylvain Lecoy
  • 947
  • 6
  • 15