I have designed my application to have two business context.
MenuBuilder - which build a menu from the input.
MenuRenderer - which render a menu from the above model.
User first send all the items to MenuBuilder and all the information are stored as a MenuBuilder domain object, an identifier is returned to the user.
And now the user want to render the menu with different color schemes. The user send the ID back and also schema details to MenuRenderer.
MenuRenderer has no idea what the menu looks like, so it has to go MenuRepository to fetch the Menu, and build a MenuRenderer object.
This might have violated the DDD principal by having that cross domain problem. Some options that I can think of.
Option 1
The user use the id to fetch the Menu from MenuBuilder and use that to create a new request for MenuRenderer, basically copy most of the items and put it into a new struct. This is probably the best isolation but it also seems unnecessary to duplicate the items. If performance is an issue, this might not be a good idea, because now you will have to send a large object instead of an ID.
Option 2 The user pass the ID to MenuRenderer, the MenuRenderer reaches out to MenuBuilder via an interface to fetch the Menu item. The MenuRenderer then do the mapping and map all the fields back to the domain context.
However, I am no sure who should perform the mapping.
Option 2.1
Define a repository interface, GetMenu(id) MenuRenderer.Menu, the database will figure how to do the mapping. And the MenuRenderer app layer just need to call GetMenu(id) to get a MenuRenderer.Menu object and pass it down to the domain logic.
Option 2.2 The MenuRenderer AppLayer calls a repostiory that returns MenuBuilder.Menu object, and perform mapping.