Currently I’m building a project with DDD about food store. The description pretty simple, the user can create his own store.
Each store has foods and each food has several food options.
The user can add food and food option of specific food options from many store
Let stay focus on the store since I found the implement for both order and store are exactly the same
The behaviour of store and food nearly the same which are just CRUD while keep in mind that food from the same store and food option from the same food don’t have a duplicated name. I known it is bad pratice for using CRUD on the domain model but I couldn’t the way out.
I tend to have 2 aggregate root: Store and Food.
Store aggregate: manage food
Food aggregate: manage food option
But that will make this become nested aggregate which is the thing should be avoided when designing.
My question is, how can I redesign to avoid the nested aggregate? Or wider, how can I apply DDD for my project which some business logic mainly lie order

It end up with the case above or the store manage both food and food option