DDD模式中Repository与Service的职责边界及分层疑问

问题1：是否需要让Service封装Repository并暴露CRUD操作，还是应按需直接使用Repository或Service？ #

不需要强制让Service统一封装Repository的CRUD操作，核心是根据操作是否包含业务逻辑来选择：

• 纯单实体CRUD（比如仅查询单个用户、无规则校验的创建用户）：直接在应用层调用Repository即可，这类操作只是数据持久化动作，没有业务规则，多一层Service封装反而增加冗余。
• 带业务规则的CRUD或多实体交互操作：必须用Service封装。比如创建用户时要校验密码复杂度、关联默认角色，或者删除用户时要同步清理其关联的权限记录，这些业务逻辑需要收拢在Service中，避免规则散落在应用层或其他地方，保证业务逻辑的一致性和可维护性。

简单说：Service是用来承载业务逻辑的，不是Repository的“统一门面”，按需选择调用方式即可。

问题2：能否在Domain和Infrastructure层分别存在UserService？ #

可以，但不是把同一个UserService拆分到两层，而是要按职责拆分成不同类型的服务，避免混淆：

• Domain层的User领域服务：命名可以是UserDomainService，仅依赖领域内的抽象（比如IUserRepository、领域实体/值对象），负责处理纯领域逻辑，比如用户权限转移规则、积分计算逻辑，完全不依赖EF Core、第三方组件等基础设施。
• Infrastructure层的User基础设施服务：命名可以是UserAuthService或UserPersistenceService，负责处理依赖基础设施的逻辑，比如调用第三方认证接口、实现特定的批量数据查询（依赖EF Core的特性），这类服务可以依赖Repository的实现或其他外部资源。

关键原则：Domain层的服务必须保持“纯洁性”，只依赖领域内的抽象；Infrastructure层的服务负责对接外部资源，实现领域层定义的抽象或处理非领域的技术逻辑。不要在两个层用同名的Service，否则会导致职责混乱，违背DDD的分层原则。

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