LLD面试中类设计的核心驱动因素及分层设计疑问

1. LLD面试的核心驱动因素 #

LLD设计要以领域模型为基础，用例/访问模式做优化，数据库实体是后续持久化的实现细节，优先级靠后：

• 先从领域关系入手：先梳理清楚核心业务对象的归属和关联（比如问题包含答案、评论），这是面向对象设计的根基，保证模型符合业务直觉
• 再结合用例调整：比如“通过ID获取答案”这类高频用例，不能让调用方遍历所有问题，这时候就要在服务层或者领域层补充优化逻辑，而不是一开始就盯着数据库表结构
• 数据库实体是实现细节：面试中不用过早绑定数据库设计，它是持久化层的事，核心是先把业务逻辑和对象关系理清楚

2. LLD中使用List/Map等集合是否会混淆领域与存储？ #

可以用，但要明确集合的作用场景，就不会混淆：

• List<Answer>属于领域关系的体现：放在Question里，是为了表达“答案属于某个问题”的业务逻辑，这是领域对象的一部分
• Map<AnswerId, Answer>属于用例支撑的优化：这是为了快速查询答案而在服务层或者领域服务中维护的缓存/索引结构，不是持久化层的设计。面试中提这个的时候，要说明它是用来满足“按ID查答案”的用例，而非数据库存储的结构，就不会混淆关注点

3. 资深工程师如何划分各层职责？ #

• 领域对象：只负责自身的业务规则和核心属性，比如Question要包含标题、内容、创建时间，以及判断是否可编辑、计算得分这类和自身相关的逻辑，不处理跨对象的查询或持久化
• 服务层：协调多个领域对象，处理跨对象的业务逻辑和用例，比如“按ID查答案”的逻辑由服务层实现——它可以调用仓库层获取数据，或者维护一个内存索引来加速查询；另外像“提交问题并通知关注者”这类跨对象流程也由服务层负责
• 仓库/DAO层：屏蔽底层数据库细节，只提供数据的持久化和查询接口，比如getAnswerById(long id)、saveQuestion(Question question)，不用关心内存中的集合结构
• 持久化模型：和数据库表结构一一对应，可能和领域对象不完全一致。比如QuestionEntity会包含用户ID外键，而领域对象Question可能持有User对象的引用；持久化模型只负责数据存储，不包含业务逻辑

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