# 1. 为何两个上下文间不应直接共享数据库（应为防腐层） A 界限上下文共享数据库不影响独立演化 B 共享数据库让上下文模型更清晰 C 防腐层直接暴露对方数据库 D 两个上下文不应直接共享数据库，应通过防腐层转换模型 ✓ 正确答案
# 2. 共享内核（Shared Kernel）的风险与适用限制 A 共享内核适用于所有上下文 B 共享内核共享整个数据库 C 共享内核不会产生耦合 D 共享内核共享部分领域模型，但带来耦合，仅适用于小且稳定的协作场景 ✓ 正确答案
# 3. 如何避免"贫血模型"，把行为放回实体而非仅 getter/setter A 贫血模型实体内部包含所有业务行为 B 贫血模型实体只有 getter/setter，业务逻辑散在 Service；应把行为放回实体 ✓ 正确答案 C 实体只做数据存储，行为都在 Service 是 DDD 推荐 D 避免贫血模型就是让实体只有字段
# 4. 实体（Entity）与值对象（Value Object）在身份与可变性上的区别 A 实体的身份 ID 贯穿生命周期且可变，值对象无身份、不可变、按值比较 ✓ 正确答案 B 值对象有身份且可变 C 实体按属性值比较相等 D 值对象创建后可以修改
# 5. Specification 模式如何把查询/业务规则对象化并可组合 A Specification 与业务规则无关 B 规范只能判断单个条件，无法组合 C 规范必须硬编码在查询中 D Specification 把业务规则对象化，并支持 and/or/not 组合 ✓ 正确答案
# 7. 工厂（Factory）与构造函数在复杂聚合创建中的职责 A 构造函数负责复杂聚合的组装与校验 B 复杂聚合的创建用工厂负责组装、校验与 ID 生成，构造函数用于简单对象 ✓ 正确答案 C 工厂只创建简单对象 D 聚合创建不需要校验不变式
# 8. 上下文映射（Context Map）的合作关系（ACL/OHS/PL）类型 A 上下文映射描述类与类的关系 B ACL 用于共享数据库 C ACL 隔离转换上游模型，OHS 开放服务，PL 发布共享语言 ✓ 正确答案 D OHS 是让下游直接访问上游数据库
# 9. 为何"大聚合"会损害性能，应让聚合尽量小且内聚 A 聚合是事务边界，大聚合加载多、锁竞争严重，应尽量小且内聚 ✓ 正确答案 B 聚合越大越能保证一致性 C 聚合越大性能越好 D 聚合间应直接引用对象而非 ID
# 10. 为何把领域模型与框架注解（如 JPA @Entity）解耦更利于测试 A 领域模型与框架耦合利于测试 B 领域模型必须使用 JPA 注解 C 测试领域逻辑必须启动 Spring 容器 D 领域模型不依赖 JPA 注解，测试无需数据库与容器，可快速单测 ✓ 正确答案
# 11. 为何跨聚合的引用应通过 ID 而非对象引用以保持边界 A 聚合边界与引用方式无关 B 跨聚合应直接对象引用，方便访问 C 跨聚合对象引用利于事务一致性 D 跨聚合应通过 ID 引用而非对象引用，保持聚合边界与自治 ✓ 正确答案
# 12. 应用服务（Application Service）与领域服务的分层职责 A 应用服务包含业务规则 B 应用服务编排用例并管事务，领域服务承载跨聚合的领域业务规则 ✓ 正确答案 C 领域服务处理事务与 IO D 两者职责相同
# 13. 聚合（Aggregate）与聚合根（Aggregate Root）的一致性边界 A 聚合根不是聚合的一部分 B 外部可直接访问聚合内任意对象 C 聚合之间是强一致 D 聚合是事务一致性边界，聚合根是唯一入口，外部只能通过聚合根访问 ✓ 正确答案
# 14. 领域事件在上下文间通过消息总线传播的最终一致 A 领域事件通过消息总线异步传播到其他上下文，实现最终一致 ✓ 正确答案 B 领域事件要求跨上下文强一致 C 领域事件是同步调用的 D 事件消费无需幂等
# 15. 领域服务（Domain Service）何时该承载不属于实体的逻辑 A 领域服务承载跨聚合/跨实体、无单一归属的领域业务逻辑 ✓ 正确答案 B 领域服务承载用例编排与事务 C 所有业务逻辑都应放领域服务 D 领域服务处理 IO 与数据库
# 16. 传统分层架构（接口/应用/领域/基础设施）的依赖方向 A 传统分层上层依赖下层，但领域层应通过依赖倒置不依赖基础设施 ✓ 正确答案 B 领域层依赖基础设施是推荐做法 C 依赖方向自下而上 D 基础设施层依赖领域层
# 17. 依赖倒置（DIP）如何使领域层不依赖具体数据库/框架 A 依赖倒置就是上层依赖下层 B 领域层直接依赖具体数据库驱动 C 领域层定义接口，基础设施实现接口并由 DI 注入，领域层不依赖具体数据库 ✓ 正确答案 D 领域层必须使用 JPA 注解
# 18. 六边形（端口与适配器）如何反转依赖让领域居核心 A 六边形架构不反转依赖 B 领域直接依赖数据库适配器 C 适配器位于六边形中心 D 领域只依赖端口接口，适配器实现端口，领域居核心且不依赖外部 ✓ 正确答案
# 19. 如何识别"伪 DDD"，仅分层命名却仍是事务脚本 A 伪 DDD 的实体包含丰富业务行为 B 伪 DDD 只有分层命名，实体贫血、业务逻辑在 Service 中，仍是事务脚本 ✓ 正确答案 C 只要分层就一定是 DDD D 伪 DDD 业务规则在聚合内
# 20. CQRS 与 DDD 的契合中写侧聚合+读侧专门模型 A 读侧也走聚合 B 读写侧共用同一模型 C 写侧用聚合承载业务逻辑，读侧用专门读模型，通过事件连接 ✓ 正确答案 D CQRS 与 DDD 无关
# 21. Clean Architecture 同心圆与 DDD 层的对应关系 A Clean 的实体/用例对应 DDD 领域层和应用层，框架对应基础设施层 ✓ 正确答案 B Clean 的依赖方向由内向外 C 框架层是核心 D 两者分层完全无关
# 22. Repository 如何为聚合提供"集合式"持久化抽象 A Repository 暴露数据库表结构 B Repository 让领域层直接依赖 SQL C Repository 以单个字段为粒度操作 D Repository 为聚合提供集合式持久化抽象，屏蔽 SQL/ORM 细节 ✓ 正确答案
# 23. Repository 的实现如何在事件溯源下变为事件存储 A Repository 的 save 变为追加事件，findById 变为重放事件重建聚合 ✓ 正确答案 B Repository 直接更新状态行 C Repository 接口需要改变 D 事件溯源下 Repository 不保存任何数据
# 24. 为何 Repository 不应泄露 ORM/SQL 细节给领域层 A Repository 接口只暴露领域语义，封装 ORM/SQL，避免领域层耦合持久化 ✓ 正确答案 B Repository 接口应暴露 SQL 条件 C Repository 让领域层依赖 EntityManager D Repository 泄露 ORM 细节利于测试
# 25. 在一个组织中推行 DDD 时最常见的组织/沟通障碍 A 主要障碍是组织沟通：通用语言、专家参与、边界划分与团队协作 ✓ 正确答案 B 障碍主要是技术实现难度 C 领域专家无需参与建模 D 通用语言与建模无关
# 26. 在微服务中每个服务是否都应有独立领域模型与边界 A 每个小功能都应该拆成一个服务 B 所有服务共享同一领域模型 C 服务边界与业务无关 D 每个服务应有独立领域模型与数据边界，但按业务子域划分，不强行细拆 ✓ 正确答案
# 27. 如何用不变式（invariant）定义在聚合内必须始终成立规则 A 不变式可以在变更后临时违反 B 不变式是聚合内必须始终成立的规则，通过聚合根方法在变更时校验 ✓ 正确答案 C 不变式由 Service 层任意修改 D 不变式与聚合边界无关
# 28. 如何用事件风暴（Event Storming）快速梳理领域模型 A 事件风暴只关注技术实现 B 事件风暴以领域事件为主线，协作梳理业务并识别聚合与界限上下文 ✓ 正确答案 C 事件风暴是单人工写代码 D 事件风暴不涉及领域事件
# 29. 界限上下文（Bounded Context）如何划分自治的领域边界 A 所有上下文共享同一模型 B 界限上下文按业务子域与通用语言划分，每个上下文自治、独立模型与数据库 ✓ 正确答案 C 界限上下文与业务无关 D 上下文之间可任意共享数据库
# 30. 领域事件（Domain Event）如何在聚合内显式表达状态变化 A 领域事件不需要记录状态变化 B 领域事件是聚合内部私有状态 C 领域事件在聚合状态变化时显式创建，记录事实并触发副作用 ✓ 正确答案 D 聚合状态变化不发布事件
