创建另一个聚合的内部方法

发布于 2025-02-10 17:00:23 字数 968 浏览 2 评论 0 原文

因此,假设我有:

  • 时间表聚合
  • 成员聚集(具有角色:操作员和批准者)

在业务角度,操作员将根据其时间表工作创建时间表。

以前,我使用用例来检查角色是否有效

使用用例:

createTimesheetUseCase(props)
  member = memberRepository(props.memberId); // assume always return member
  if (member.role != ROLE.OPERATOR)
    throw ForbiddenCreateTimesheet();
  timesheet = TimesheetFactory.create(props);
  timesheetRepository.save(timesheet);

但是我想知道我是否可以在成员聚集中创建时间表聚合?

在代码中可能是这样的:

createTimesheetUseCase(props)
  member = memberRepository(memberId); // assume always return member
  timesheet = member.createTimesheet(props); // Will throw error if role is not operator
  timesheetRepository.save(timesheet);

内部成员汇总:

createTimesheet(props)
  if (this.role != ROLE.OPERATOR) throw ForbiddenCreateTimesheet();
  return TimesheetFactory.create({...props, memberId: this.id});

它是否违反了DDD?在您看来,处理这种情况的最佳方法是什么?

So Let's Say I have:

  • Timesheet Aggregate
  • Member Aggregate (Which have role: Operator and Approver)

In Business Perspective, Operator will create timesheet according to their schedule work.

Previously, I using use case to check whether the role is valid or not

Using Use-Case:

createTimesheetUseCase(props)
  member = memberRepository(props.memberId); // assume always return member
  if (member.role != ROLE.OPERATOR)
    throw ForbiddenCreateTimesheet();
  timesheet = TimesheetFactory.create(props);
  timesheetRepository.save(timesheet);

But I wonder whether I can create Timesheet aggregate inside the Member Aggregate?

In code maybe something like this:

createTimesheetUseCase(props)
  member = memberRepository(memberId); // assume always return member
  timesheet = member.createTimesheet(props); // Will throw error if role is not operator
  timesheetRepository.save(timesheet);

Inside Member aggregate:

createTimesheet(props)
  if (this.role != ROLE.OPERATOR) throw ForbiddenCreateTimesheet();
  return TimesheetFactory.create({...props, memberId: this.id});

Is it violated the DDD and what's in your opinion the best way to handle this case ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

风月客 2025-02-17 17:00:23

如果它反映了事件如何发生的商业语言和商业领域,那么在总体上拥有一种工厂方法,有责任创建另一个汇总,这当然是很有意义的。如果您使用单独的工厂课程,从我的角度来看,总汇总是一种技术性。

尽管遵循了域语言,但让成员聚集的汇总创建时间表汇总也适用于 原理。用例只告诉成员执行相应的操作,而不是要求成员提供其一些数据(执行业务逻辑)。有了数据和行为,可以更好地封装,这是一件好事。

在他的书中实施域驱动的设计沃恩·弗农(Vaughn Vernon)将其完全描述为用于汇总创作的一种可能的模式(请参阅第11章,工厂)。可以找到该章的代码示例< uct/ product.java#l134“ rel =“ nofollow noreferrer”>在这里。

If it reflects the business language and business domain on how things happen, it can of course make total sense to have a factory method on an aggregate that has the responsibility to create another aggregate. If you use a separate factory class for that inside the aggregate is a technicality from my point of view.

Despite of following the domain language letting the member aggregate create the timesheet aggregate also works towards the Tell, Don't Ask. principle. Instead of asking member for some of its data to then do the job (executing business logic), the use case rather just tells the member to perform the respective operation. With that data and behavior are encapsulated better which is a good thing.

In his book Implementing Domain-Driven Design Vaughn Vernon describes exactly this as one possible adequate pattern for aggregate creation (see chapter 11, Factories). The code sample to that chapter can be found here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文