Updating child entities in DDD - domain-driven-design

Question

Is it correct to update a child entity when it's not part of its Aggregate Root?
Lets consider an ecommerce site. There's a product entity, which has multiple variants. If we consider that the product is a T-shirt, then a product variant might be a t-shirt with a color of White or Green.
class Product {
id: number
slug: string
description: String
variants: ProductVariant[]
}
class ProductVariant {
name: string
quantity: number
price: float
images: string[]
}
Lets exclude the non-variant related rules and focus on the variants.
A variant cannot exist on its own, it must be part of a product
A product can have up to 10 variants
A variant must have at least one image, name, quantity and price
Now, how does a variant come into existence? Well, according to pt.1, our product must implement a product.addVariant(variant: ProductVariant) method, as the variant cannot exist on its own.
Since the variant contains its own logic, we can implement a factory method. For simplicity, we can assume a private constructor, so the implementation can be like
class ProductVariant {
private constructor(...) {}
public static create(productVariantProps): ProductVariant {
// Validate input, if valid
return new ProductVariant(productVariantProps)
}
// Rules for adding new images
addImage(productVariantImage) {...}
}
And the way that the product variant can come into existence can be like so
const product = await ProductRepository.find(...)
cosnt variant = ProductVariant.create({
name: "White",
quantity: 1,
price: 25.50,
images: [ ... ]
})
product.addVariant(variant)
await ProductRepository.save(product)
Error handling is excluded for simplicity, the addVariant method can return a nullable error, for example, but it can be implemented in multiple ways.
Now, this example contains a product, which enforces validation rules according to the number of variants that can be added to it, and a separate ProductVariant entity, which enforces validation rules according to itself.
In the UI, we used to have one product form for the product and all its variants were edited /created/deleted on the same page. The UX team decides that this is very complex for our customers and it would be better if we have a dedicated page for editing a variant.
So, we were editing the variants here: /products/edit/:productId, and now we'd like to have to go here /products/edit/:productId/:variantId to edit a variant.
Now, if a variant exists, all its rules/business logic are encapsulated in the ProductVariant class, so we should be able to just fetch it from the database, make our changes, and save it through the repository.
However, the ProductVariant is a child entity of the Product Aggregate Root.
I'm inclined to do something to the lines of
const variant = await ProductRepository.findVariant(req.params.variantId)
// make the changes
await ProductRepository.save(variant)
But should I? Should it be the ProductRepository? Shouldn't I only save Aggregate Roots?
From what I know, the more proper way to achieve this would be
const product = await ProductRepository.find(req.params.productId)
const variant = product.getVariant(req.params.variantId)
// make the changes to the variant
await ProductRepository.save(product)
But
It involves more work
Unnecessary data is fetched for the given operation ( one product might have many child entities, like variants, images, which have locales etc ), when I know for certain I'm only interested in this one variant
Edit: Sorry for the broken code examples, I thought I would write it in Typescript, so that its more understandable, but I'm not 100% familiar with it and very tired. Hopefully the point is clear.

Answer 1

As long as Product and Variant don't have any business rules that will affect ProductVariant, I see no reason to load extra data through the aggregate root. If this decision creates a problem in the future, just change it. Keep a pragmatic mind and don't fall into analysis paralysis.
Splitting your UI into different parts is a good idea. A Task-based UI makes it easier for you as a developer to know what is happening in the UI.
With this in mind, creating and changing ProductVariant can be implemented as a command from the UI that only handles this entity. I would use the same repository as Product for this.
I know you didn't ask for feedback on your REST API, but I recommend that you build the URLs like this /resource/:id/resource/:id/(action). This way, you rarely need to use the action part of the URL because you use the HTTP verbs to decide if you are doing a PUT (update), POST (create) or DELETE. Also, it's easier for users of your API to know what the ID represents.

Answer 2

A variant cannot exist on its own, it must be part of a product
This one can be implicitly enforced in code by making sure no code paths allow it. See answer about #2.
A product can have up to 10 variants
As we can see, the constraint that spans many variants is their count, but not the variant states per se. That means you could simply track the count in Product and involve Product in the creation and removal process of a ProductVariant. All other code paths would deal with the ProductVariant directly, which is an AR of it's own.
e.g.
// Service layer
addProduct(productId, name, quantity, ...) {
transaction {
product = productRepo.productOfId(productId);
variant = product.addVariant(name, quantity, ...); //tracks count & enforces rule
variantRepository.save(variant);
}
}
renameVariant(variantId, newName) {
transaction {
variant = variantRepo.variantOfId(varitantId);
variant.rename(newName);
}
}
A variant must have at least one image, name, quantity and price
This rule can be enforced in the ProductVariant AR itself.