某连锁餐饮集团建设了“云–端一体的点菜系统”。
终端侧（端）：部署在门店的收银机、服务员手持PAD、自助点餐机等，负责：1）桌台管理与点菜下单；2）本地订单暂存与支付；3）与云端同步菜品、价格等基础数据。
云端系统（云）：部署在集团数据中心或公有云，负责：1）菜品基础信息管理（菜品、原料、定价、上下架等）；2）订单管理（汇总各门店订单、对账、结算）；3）餐厅菜品与菜单配置（不同门店的可售菜品组合）；4）员工与权限管理；5）报表分析与运营决策。
企业计划采用领域驱动设计（DDD）方法，对复杂的业务域进行建模和拆分，同时需要考虑云端与终端之间的网络质量不稳定（弱网、间歇断网）的情况，保证点单业务“尽量可用 + 数据最终一致”。
（1）简要说明领域驱动设计（DDD）的基本思想。（2）给出“限界上下文”的严格定义，并说明其在复杂系统（如本点菜系统）中的作用和好处。
（1）DDD 强调以业务领域为中心，通过领域专家与开发人员共同建立统一语言，根据业务边界划分领域、构建领域模型，用模型驱动设计实现。
（2）限界上下文：在特定边界内，一个领域模型及其术语、规则保持语义一致的区域，边界外可以有不同含义。好处：消除概念冲突，限制复杂度，支持团队拆分与独立演进。
此题出自北京交通大学一硕士论文 《支持离线模式的易迭代餐饮系统设计与实现》。
领域驱动设计（DDD）的核心思想是：将软件设计的重心从“技术”转移到“业务领域”，通过与领域专家密切合作，形成一套贯穿需求、设计和实现的统一语言（Ubiquitous Language），围绕领域模型组织代码结构（而不是围绕数据库或技术框架）。DDD 通常会划分领域层、应用层、基础设施层等，并强调聚合、实体、值对象、领域服务等概念，用清晰的模型来承载复杂业务规则。
限界上下文（Bounded Context） 是 DDD 中最关键的划分单元，可以理解为“统一语言适用的边界”。在一个限界上下文内部，诸如“订单”“菜品”“原料”等术语有清晰且唯一的语义，模型与规则高度一致；而在另一个上下文中，同名概念可以有不同含义，例如“订单”在“交易上下文”里重支付状态，在“结算上下文”里重对账金额。
通过为复杂系统划分多个限界上下文，可以：① 控制模型规模，降低复杂度；② 避免跨团队、跨系统的概念冲突；③ 支撑团队按上下文拆分为独立服务，形成清晰的微服务边界，独立演进与部署。
本案例中，将“订单交易、菜品基础信息、门店运营、员工权限”等拆分为不同上下文，有利于分别建模和优化，避免一个庞大的“上帝模型”。