DDD - how should look-up entities be treated?

Question

We're working on a project using DDD, but are getting stuck on how to treat look-up entities. For example, we have an aggregate called "Customer" and the entity "Customer" is also the aggregate-root. The entity "Customer" has the property "CustomerTypeID".

But we also have an entity "CustomerType" respresenting all existing customer types (ID and description). There will be an admin function allowing users to maintain the customer types (i.e. adding a new customer type, etc.).

Please note that I'm not talking about changing the customer type for a specific customer, but about maintaing the list of customer types.

My apologies for the longwinded story, but here are my questions:

• am I right by thinking that "CustomerType" is an Entity and not a Value Object?

• should "CustomerType" be inside the aggregate "Customer" or should it be inside its own aggregate as we will access it and maintain it outside of the context of a specific customer?

• if this entity and any other entities which are basic lookup entities (like customer status, product type, etc.) should be aggregates on their own (and being the aggregate roots of these aggregates) am I not going to end up with hundreds of repositories? (as each aggregate root will have its own repository)

As you can see I'm getting in a muddle here and just need to be pointed in the right direction.

=================================== I tried to write some code in reply to eulerfx's reply but I couldn't get it to work so I'll put it here.

In regards to point 2, on screen we'll obviously only ever show the type's description (for example "Personal"). Would that mean I'd end up with something like this?:

Public Class Customer
    Inherits EntityBase(Of Integer)
    Implements IAggregateRoot

    Public Property CustomerID As Integer
    ...
    Public Property CustomerType As CustomerType
    ...

and

Public Class CustomerType Inherits EntityBase(Of Integer) Implements IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

Or should the property inside the class "Customer" be CustomerTypeID?

Regarding to point 3, what's the difference between an aggregate and a bounded context? Wouldn't the "Customer" aggregate (with "Customer" being the aggregate root), which also contains any entities and value objects which only exist inside the context of Customer, not be a bounded context?

Answer 1

1. Yes, since CustomerType has an identity and an associated description it is an entity.

2. Whether the Customer class has a CustomerType property or a CustomerTypeId property depends on whether it needs access to other properties on CustomerType. Either way, CustomerType is its own entity having its own repository.

3. If you have hundreds of entities, specifically of the type you specified, then it could be an indication that the project is getting too big and you may need to partition into appropriate bounded contexts.