I know the title is confusing, I didn't how to word it.
I'm studying the Domain Driven Design (DDD) and I'm reading the book "NET Microservices Architecture for Containerized NET Applications" from microsoft and I can't understand well how to identify the aggregate roots.
If I understand it correctly the OrderItem has a ProductId which identifies a product that should be another Aggregate Root if I'm not mistaken (note that in the source provided by the book there is no Product Aggregate and the product does not exist in the model, but I suppose it's for simplicity).
Now I expose the problem imagine we have an Aggregate Root TaxesDetail which OrderItem has a reference to it, and this TaxesDetail is added with the taxes of the product and the taxes of the buyerID and some other values when creating an OrderItem. If only the OrderItem could create the TaxesDetail then TaxesDetail will simply be a child entity, but if we have an Aggregate Root of an Offer that has an OfferItem (with some different field than OrderItem) which in turns have a TaxesDetail then what should the TaxesDetail be? An AggregateRoot? A Child Entity? If it's a child entity then we would have to create an OrderTaxesDetail and an OfferTaxesDetail which will duplicate the code.
This is just an example but what I'm trying to understand is the concept of Aggregate Root, how to identify one, if it's possible that multiple Aggregates Root can create the same Aggregate Root...
An edit to respond @Christophe since a comment can't be too long.
In the case of identity I think if you change and OrderDetail you can just delete the old TaxesDetail and create a new one, I don't think there is a need to keep track of the older TaxesDetail.
Now I see how it is a Value Object. In the first point, we can see that it's lifespan is entirely dependant on the Aggregate Roots of OrderDetail and OfferDetail. In the second point, we can see it's immutable if, for example, an OrderDetail it's changed the TaxesDetail won't change, the TaxesDetail will be destroyed and constructed with the new properties.
As you said I had in mind the implementation considerations and how the model was constructed, I didn't start my design from a domain approach and I was mixing the domain layer with the persistence layer. I should pay more attention the next time.
Thanks for your help!