DDD - how to handle search related objects?

Question

We are working on a project using DDD, but focus on how to handle search objects. For example, we have an aggregate called "Client", and the entity "Client" is also an aggregated root. The Client object has the CustomerTypeID property.

But we also have a "CustomerType" object representing all existing customer types (identifier and description). There will be an administrator function that allows users to support client types (i.e. add a new client type, etc.).

Please note that I'm not talking about changing the type of client for a particular client, but about how to set up a list of client types.

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

• Did I understand correctly that "CustomerType" is an object, not an object of value?

• should CustomerType be inside the Customer aggregate or should it be inside its own aggregate, since we will access it and maintain it outside the context of a particular customer?

• if this object and any other objects that are the basic objects of the search (for example, customer status, product type, etc.) must be aggregates by themselves (and are the aggregate roots of these aggregates), I’m not going to end up with hundreds repositories? (since each aggregate root will have its own repository)

As you can see, I'm confused here and you just need to point in the right direction.

==================================== I tried to write code in response to the eulerfx answer, but I could not make it work, so I'll put it here.

With respect to point 2 on the screen, we obviously will only show the type description (for example, "Personal"). Does this mean that I will get 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 Client class be CustomerTypeID?

Regarding point 3, what is the difference between an aggregate and a limited context? Will the “Client” aggregate (with the “Customer” be an aggregated root) that also contains any objects and value objects that exist only within the Client’s context, and not be a limited context?

Answer 1

• Yes, because CustomerType has an identifier and associated description, it is an entity.

• The Customer class has the Customer property or the CustomerType property, depending on whether it needs access to other properties on CustomerType . In any case, CustomerType is its own object, which has its own repository.

• If you have hundreds of entities, in particular of the type you specify, this may be a sign that the project is becoming too large, and you may need to be divided into appropriate limited contexts.