1

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?

RiddleMeThis
  • 851
  • 1
  • 8
  • 18

1 Answers1

0

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).

T1Space
  • 71
  • 1
  • 8
  • Thanks, that's an interesting point. However, to my understanding, DTOs are just data, i.e a list of properties with public getters and setters, used for transferring data, such as reading data from a db. In real life (non-trivial) examples, I find domain objects might be readonly within a particular bounded context, in the sense that they are not persisted. But they still have methods with take parameters, encapsulate data and behaviour, and even maintain a transient internal state (i.e. rich domain models vs POCO/POJO DTOs). In light of that, would you still say these objects are DTOs? – RiddleMeThis May 02 '23 at 17:45