Define one repository per aggregate

[augustolopez]

For each aggregate or aggregate root, you should create one repository class. It is recommended, you can see an example by Microsoft:

Here #130 it is mentioned that repositories are used to retrieve a domain entity
In this case #132 A repository of an entity is injected into the AR repository so that all operations go through the AR repository. So for this practical case OrderItemRepository is also injected into OrderRepository

So having multiple repositories with multiple mappers, my doubt is whether this is the correct way:

If a customer updates the remark of their order, they would first retrieve the order:

const order = orderRepo.findOneById('id')

If an order exists everything is fine, I would have partially my order already mapped as "OrderEntity" and I could update the remark

order.setRemark(remark)
order.save()

In this case there was no problem partially bringing the order without its items, since there is no invariant directly related to the remark, but is lazy loading really good?

In this second case, apart from modifying the comment, the client also deletes an item
You should do the same as the first part and also add the item

const order = orderRepo.findOneById('id')
const items = orderRepo.findItemsByOrderId('id')
order.addItems(items: OrderItemEntity[])

In this way I would have completed my order and I could carry out operations calmly knowing that the invariants will be fulfilled

order.setRemark(remark)
order.removeItem(Item: OrderItemEntity)
orderRepo.save()

Is this the correct path suggested?
If I know that my order will always need to have the items, wouldn't it be better for performance reasons to make a single query, map the response and in this way also avoid lazy loading?

[Sairyss]

Do you experience any performance issues that you need lazy loading? I would suggest against it for most cases, you don't need lazy loading unless you have performance issues. Also it's pretty error prone, you can easily forget to load items since you do it manually.
I would just load everything in the repository and map it to Order before it's returned, so anybody who loads the Order doesn't need to worry about populating it with items.

[khaelys]

In this example I agree, but this case is not impossible. I've read some answers on StackOverflow that suggests to split Order and OrderItem in two AR and deal with eventual consistency, what do you think?

[Sairyss]

When you have such high amounts of data that loading it in memory would be too slow, solution heavily depends on the use case and needs benchmarking.

Considering Order-Items scenario, here are some suggestions:

• If for some reason you need to load it in memory, you can load a subset of items data and benchmark the performance for it. For example 1000000 items in a format { id : UUID, price: number } would take around 80mb of memory. It may or may not be too slow for you, depending on how many orders of that size you have and how many users is using the app.
• In some cases there is no need to load it in memory, for example if you need to get a total price of such order you could just query a sum (or anything) directly in the database: select sum(i.price) from orders ... join items as i on ... where order_id = 123 .
• You could load items in batches and process them per batch.
• You can create eventually consistent "projections" or "materialized views" that keep aggregated data of the order and update every time an item is added, so you don't have to load all the items every time, you just load aggregated data directly.

There are plenty of options, each depends on your requirements and application architecture.

[augustolopez]

I probably expressed myself incorrectly, my point was as follows:
By having n domain entities and n repositories, you are forced to make multiple queries and build the entity as shown in this case:

const order = orderRepo.findOneById('id')
const items = orderRepo.findItemsByOrderId('id')
order.addItems(items: OrderItemEntity[])

Following this path, you must always verify that your entity is built correctly with all the necessary data to be able to work.
My question was more along these lines, why would it be incorrect to make a single query?

export const OrderWithItemsSchema = orderSchema.extend({
  items: z.array(orderItemSchema),
});

export interface OrderWithItemsModel extends OrderModel {
  items: OrderItemModel[];
}

async findOneById(id: string): Promise<OrderEntity> {
  const statement = sql.type(orderSchema)`
  SELECT orders.*,
  COALESCE(
    (
      SELECT JSONB_AGG("orderItems".*)
      FROM "orderItems"
      WHERE "orderItems."orderId" = orders.id
      ), '[]'::jsonb
    ) AS items
  FROM orders
  WHERE orders.id = ${id}`;

  const record = await this.pool.one(statement);
  return this.mapper.toDomain(record);
}

toDomain(record: OrderWithItemsModel): OrderEntity {

    const items = record.items.map((items) => {
      return new OrderItemEntity({
        id: item.id,
        createdAt: new Date(item.createdAt),
        updatedAt: new Date(item.updatedAt),
        props: {
          // props
        },
      });
    });

    const entity = new OrderEntity({
      id: record.id,
      createdAt: new Date(record.createdAt),
      updatedAt: new Date(record.updatedAt),
      props: {
        items
      },
    });

    return entity;
  }

This way you ensure that you have your entity completely built and avoid multiple queries in this case.

[Sairyss]

1 query is totally fine, I don't see much benefit of creating 2 repositories for this.

N entities doesn't mean you need N repositories, it's N repositories for N aggregate roots.

Order is your aggregate root, so everything that this aggregate needs can be loaded in a single repository and even a single query.

Microsoft diagram that you shared above does not conflict with that as far as I understand.