领域服务
在领域驱动设计(DDD)
解决方案中,核心业务逻辑通常在聚合 (实体) 和领域服务中实现. 在以下情况下特别需要创建领域服务
- 你实现了依赖于某些服务(如存储库或其他外部服务)的核心域逻辑.
- 你需要实现的逻辑与多个聚合/实体相关,因此它不适合任何聚合.
ABP 领域服务基础设施
领域服务是简单的无状态类. 虽然你不必从任何服务或接口派生,但 ABP 框架提供了一些有用的基类和约定.
DomainService 和 IDomainService
从 DomainService 基类派生领域服务或直接实现 IDomainService 接口.
1 | using Volo.Abp.Domain.Services; |
当你这样做时:
- ABP 框架自动将类注册为瞬态生命周期到依赖注入系统.
- 你可以直接使用一些常用服务作为基础属性,而无需手动注入 (例如 ILogger and IGuidGenerator).
建议使用 Manager 或 Service 后缀命名领域服务. 我们通常使用如上面示例中的 Manager 后缀. 示例: 实现将问题分配给用户的领域逻辑
1 | public class IssueManager : DomainService |
问题是定义如下所示的 聚合根:
1 | public class Issue : AggregateRoot<Guid> |
使用 internal 的 set 确保外层调用者不能直接在调用 set ,并强制始终使用 IssueManager 为 User 分配 Issue.
应用程序服务与领域服务
虽然 应用服务 和领域服务都实现了业务规则,但他们存在根本的逻辑和形式差异:
- 应用程序服务实现应用程序的 用例 (典型 Web 应用程序中的用户交互), 而领域服务实现 核心的、用例独立的领域逻辑.
- 应用程序服务获取/返回 数据传输对象(Dto), 领域服务方法通常获取和返回 领域对象 (实体, 值对象).
- 领域服务通常由应用程序服务或其他领域服务使用,而应用程序服务由表示层或客户端应用程序使用.
生命周期
领域服务的生命周期是 瞬态 的,它们会自动注册到依赖注入服务.
总结
- 不要在领域层,持久化实体数据到数据库中。应该在应用服务层持久化数据。
- 将实体对象作为方法参数,而不是其id值。如果接受其id值,则需要从领域服务内的数据库中检索实体。这种方法使应用程序代码在同一请求(用例)的不同位置多次加载同一实体,这是低效的,并导致错误。