DDD聚合嵌套设计疑问：餐厅菜单领域模型实践咨询

领域场景 #

我们运营连锁餐厅，各门店菜单略有差异但存在重叠，计划搭建网站展示菜单（后续会新增在线点餐功能）。初步建模的实体包括：

• Restaurant（门店）
• Menu（菜单）
• Menu Category（菜单分类）
• Menu Item（菜品）

我原本设想实体间为UML组合关系：
[组合关系示意图]

• 门店拥有菜单：包含1个活跃菜单、若干草稿菜单、历史菜单列表；菜单无法脱离门店单独管理，删除门店时需级联删除所有菜单，仅草稿菜单允许编辑
• 菜单包含分类集合，需维护分类顺序；菜单处于只读状态时不允许任何修改，支持级联删除
• 菜单分类同理包含菜品集合；菜品不可跨菜单复用，菜单激活后菜品即变为不可变快照

核心疑问 #

查阅的DDD资料中鲜见多层聚合的示例，通常都是聚合间相互引用而非嵌套结构，因此有以下疑问：

1. 我对DDD中聚合的使用场景理解是否正确？还是应当将这些实体都设为独立聚合？
2. 多层聚合是否可行？属于不良实践吗？会带来后续问题吗？

另外，希望获取该主题的优质阅读资料、视频或播客推荐。

对已有回答的思考 #

我理解关于Restaurant实体的相关观点，但最困惑的是Menu及其内容的设计：

• 如果将聚合视为粗粒度锁，嵌套聚合显然不合理；但从领域视角来看，Menu是一个完整的整体，包含菜品集合，菜品不能随意修改、不可跨菜单复用，还需维护菜品顺序等，因此将MenuItem置于Menu内完全符合DDD原则
• 但需要将菜品按Category分组，同时要维护Menu内Category的顺序、Category内MenuItem的顺序。我考虑过让Menu作为聚合根，同时包含Category集合和MenuItem集合，但这样Menu实体会不会因管理分类和菜品的逻辑而过度臃肿？
• 也考虑过将Category当作Item的标签（可能是值对象？），但这样谁来维护Category内MenuItem的顺序？

内容的提问来源于stack exchange，提问作者Alexander Burov