Where should I create my aggregate root? in api or frontend?

Question

I am writing a simple application to apply what I have learned so far in DDD.

I have the following mysql tables in my api server

Sales

Column
id	pk, int
title	varchar
description	varchar

Images

Column
id	pk, int
url	varchar
sale_id	fk, int

I have the following endpoints

GET /v1/sales
GET /v1/sales/:id
POST /v1/sales

On the frontend I have a SaleView which displays the sale with the information AS WELL AS the images.

So my question is when the SaleView loads, should the frontend call GET /v1/sales/123 and then call GET /v1/sales/123/images (I have to create this one) or should it just call GET /v1/sales/123 and it automatically aggregates the images into the response? or finally should I make another endpoint to do aggregation such as GET /v1/salesAggregate/123?

I am not quite sure. The other solution I have in mind is create entities without thinking about database. For example:

SaleEntity

var id: UUID
var title: String
var description: String
var imagesUrls: [String]

and keep my endpoints the same and the first design refers only to the database design so when I get an api call to GET /v1/sales/123 all I do in the controller is query the Sales table as well as the Images table and then create a SaleEntity which then gets mapped to the response of the endpoint?

I am leaning more towards the last solution, but I am confused as which is the correct path to take. I know both works but I would like to learn the correct habits.

• Laiv: Both are fine and both have very little to do with DDD. So, why is DDD relevant to this question?
• Doc Brown: @Laiv: DDD incorporated ideas like aggregates which are surely older than the term DDD itself, or can be used without other DDD concepts. Nevertheless it is not uncommon for people today to ask about these ideas as if they were "DDD exclusive".
• Laiv: The problem is then that the possible answers are left to interpretation. Yours is good and I upvoted it because I find it useful. However, mine would touch on different subjects as if it was different question. That's why I ask why is DDD relevant. If it's not, then the question is about API modelling regardless DDD. If it's, then yours hits the nail because it covers the two subjects.
• emhsmath: @Laiv my thinking was to model the problem in DDD but I understand where I went wrong. Thank you for the comment and clarification.

Answer 1

If you truly want to treat sale entities (with images included) as an aggregate in your domain model, you should not allow to GET or PUT sales and images individually, and use your SaleEntity model as a blueprint. Citing Fowler:

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries.

Let me add that the ideas of a "correct path" or "correct habits" look off-track to me. The approach of treating sales and images individually (and so as entities / aggregates on their own) is neither more nor less correct - it is just a different design decision.

Of course, one of the two decisions may be better suited for creating your specific application. This depends ultimately on what your system will finally do with those entities. If sale entities together with the images can always be treated as a unit (for example, in any load and save operations, or maybe by certain business logic operations), go ahead with your "SaleEntity with images" model. If, however, you may want to allow image entities with an empty sale_id, with operations on them outside of a "sale" context, then you better implement those two entities separately and provide separate endpoints.

• emhsmath: Thanks a lot, this makes sense. I did more reading + your answer clarified some things. I understand my problem is that I was thinking from the persistent layer rather than thinking about my "domain" which mislead me and probably made me ask the wrong question.I also understand the above is not that big of a deal to think in DDD but I am learning and I wanted to apply what I learned even if it is on a small scale. I am reading the blue book. Thank you