Question

在BC省，我有以下规则：

A project can be defined by an employer.
An approver should approve the project.
Then an employee can bid that project.
A project can be directed by a member (= an employer or an employee) to another member.

该项目是雇主，雇员和审批人的独立集合。

雇主，员工和审批人都是用户，我需要向BC用户了解他们的身份。

我设计的项目包括方法：

static Define(){...}
ApprovedBy(approderId){...}
Bid(bidderId){...}
Direct(directorId,directeeId){...}

我应该如何将其他无所不在的语言应用于上下文？

我是否应该在此上下文中跳过Users或为员工，雇主和审批人创建类，并将Approve方法设为内部，以便限制应用层只能批准项目通过Approver类，如下所示？

class Approver{
    approverId _id 
    public Approver(approverId id){
        _id = id
    }
    public Approve(project){
       project.ApprovedBy(_id);
    }
}

更新

以下是一些关于答案的评论，可能会使问题更加清晰：

Approver是Identity and Access BC中定义的角色，唯一匹配的是它的角色名称。Bidder应该填写一些额外的数据而不是常规会员能够bid a project。我想使用saga并听取events来检查投标人是否满足规则，然后saga将AddRole()或RemoveRole()发送给I＆amp;一个BC。我这样认为我有一个更有凝聚力的I&A关注点，它与系统的其他部分分开，但当我设计Project BC时，我想为什么不调用类似factories.Employer(‌employerId).DefinePro‌ject(..)的东西

BUT

我担心的是未来功能，这些功能会在首次发布后增长。例如，Employer可能需要更多规则，并且当我开始将它们添加到不列颠哥伦比亚省，我必须打破我的测试，以避免Project泄露Employer的责任，例如，我不能再将DefineProject()称为static factory constructor（或project），定义Employer.DefineProj‌ect();的唯一方法应该是调用Approvement，我觉得Approver应关注的自然地方是role contracts课程。您认为我是工程学吗？

我们在ddd中将所有内容甚至身份封装在另一个对象中的原因之一是通过定义对象之间的显式契约并让它们在另一个上下文中更改其内部实现来独立地处理需求的更改.PO没有关注身份，但他明确地谈论角色及其规则。这可能会影响我的测试和服务层代码。我不应该至少像身份一样照顾角色吗？或者我误解了有关边界和合同的事情？

明确的摘要anti corruption layer可以充当潜在的interface OCP，这可以让我远离打破function quote(float $a){ var_dump(func_get_args()); } quote(1.1071212);吗？

Answer 1

我不会对演员的操作进行建模，因为操作的自然之家是聚合。但是，如果您明确地对角色进行建模，则可以免费获得角色安全检查，并与您的无处不在语言保持一致。显式角色将成为反腐败层的一部分，这些类可以通过一个服务实例化，该服务将您与Idendity＆amp;的集成抽象化。访问BC。

E.g。

Approver approver = actorService.approverOfId(userId);
project.markAsApprovedBy(approver);

这种方法在Vaughn Vernon的IDDD书和blog post中进行了讨论。

Answer 2

我的意见：

请记住，您的模型只是对您的上下文（需求集）有用的表示。如果您的要求发生变化，那么您的模型将会自然发展。因此，测试破解是一件好事。我知道你想要预见变化，但不要过多地思考。也许企业会对基于角色的访问控制感到满意。

如何在“IAM BC”中使用“Approver”而不是在“Project BC”中引入“Project Member”或“Team Member”概念。该成员是一个党（雇主，雇员和审批人）在项目背景下扮演的角色：

ApprovedBy(memberId){...}
Bid(memberId){...}
Direct(directorId,directeeId){...}

像这样你的项目只需要知道成员。或者相反。你的政党只需要知道他们扮演的角色。所以Project和你的派对都是脱钩的。此外，一名员工可以在项目中扮演多个角色（作为团队成员）。

您可能需要在“Identity and Access BC”和“Project BC”之间集成（反腐败层？），以防您的角色发生变化，这可能会影响您的项目/项目成员。

围绕聚合根操作包裹域角色以表示无处不在的语言

2 个答案: