DDD repositories, and REST

Question

Should DDD Repository always return aggregate and all it's value objects and entities?

For an example, I have Invoice object which has it's type and items.

Invoice
  --Id
  --Issuer
  --InvoiceType
  --Items

Data are persisted in 4 SQL Tables.

Invoices (FK to invoice type, FK to issuers),
InvoiceTypes
Items(fk to Invoice)
Issuers

If a repository should always return aggregates in it's full state, is it a bit of overkill to include InvoiceType and Items if i need to fetch 50 invoices, and display only ID and IssuerName.

Example for

InvoiceRepository
{
  //should this also fetch InvoiceTypes and items from SQL, or i need separate invoice model for this
  public List<Invoice> FetchForListing(int page, int take);
}

VoiceOfUnreason VoiceOfUnreason · Accepted Answer · 2016-06-28T14:45:20

Should DDD Repository always return aggregate and all it's value objects and entities?

No. In use cases where you are going to be performing a write, you should load everything, because you need the full internal state to ensure that your change satisfies the invariant.

But if you are only going to perform a read, the full state isn't necessary at all -- it's reasonable to limit to the data you pull out.

(For example: when using the cqrs pattern, reads tend to not touch the aggregate at all, but instead copy data from "projections" of aggregate state into a more suitable representation.)

InvoiceRepository
{
    // should this also fetch InvoiceTypes and items from SQL, 
    // or i need separate invoice model for this
    public List<Invoice> FetchForListing(int page, int take);
}

So in this case, you wouldn't return a List<Invoice>, since that isn't what you want, and you might not use the same interface to represent the repository

InvoiceSummaryRepository
{
    public List<InvoiceSummary> readSummary(int page, int take);
}

Check in your own ubiquitous language to figure out what InvoiceSummary is actually called, to determine whether List<InvoiceSummary> is actually a thing with a name of its own (likely is you are using it to build the representation of a resource in your REST api), and so on.

DDD repositories, and REST

1 Answers