DDD: are domain objects with aggregated properties entities and value objects?

Question

Sometimes I need a representation of an object which is basically the representation of values returned by a query of multiple tables with aggregate values, but might still be identifiable by an ID or composite ID.

As a contrived example, I might have a Customer entity:

public class Customer : Entity<int>
{
    public string Name { get; private set; }
    public Address Address { get; private set; }
    // etc.
}

This corresponds to the Customer table in the database.

Now imagine I have some business logic which is using the customer's interactions, such as how many items they've purchased in the past month. This might be represented as follows:

public class CustomerInteraction
{
    public int CustomerId { get; private set; }
    public int numberOfPurchasesInThePastMonth { get; set; }
    // etc.
}

This might be read from a query or a stored procedure, which does an inner join on the Customer table and the Order table, and sums the user's order totals over the past month.

Would this object be an entity, a value object, or something else?

It doesn't feel like an entity in the same way that Customer entity does, since doesn't have its own ID. Its properties are calculated from the Customer and Order tables, rather than a CustomerInteraction table with a CustomerInteractionId.

But equally, it doesn't feel like a value object, in the sense that if I had a dictionary or a HashSet of customer interactions, I'd want the equality comparison to compare the CustomerID, not do a memberwise comparison of all the properties. In terms of identity, you can't have the same customer making a different number of purchases over the past month.

Therefore, what kind of object would CustomerInteraction be?

Answer 1

Entities, Aggregates and Value Objects all have one thing in common: they contain business logic. When you interact with these kind of objects, there are business rules that need to be checked. The object CustomerInteraction does not seem to have any business rules and is simply a data transfer object (DTO). Business rules are (usually) only important if you want Update, Create or Delete, not when you Read. You could read about CQRS to learn more about separating Queries (Read) from Commands (Update, Create, Delete).