【问题标题】：How to make aggregate root smaller [closed]如何使聚合根更小[关闭]
【发布时间】：2019-07-25 19:44:49
【问题描述】：

发生了什么

我正在开发使用一次性密码处理操作确认的内部微服务。我决定创建良好的域模型使用事件溯源方法。

我有什么

我为某个操作类型的操作有确认会话。用户可以为 Confirmation Attempt 添加询问 Session 并指定他想要接收 Challenge 的Channel（一个-时间密码）。 Channel 类似于 SMS、E-Mail、Push 等。

这是命令处理程序的代码摘录

var session = _sessionFactory.CreateSession(operationType, userId);

var challengeCreationResult = await _challengeProvider.CreateAsync(
    recipient, channelType, session, addOnFields);

if (!challengeCreationResult.IsSuccess)
{
    return OperationResult<AttemptCreationResult>.Error(
        challengeCreationResult.ErrorCode, challengeCreationResult.ErrorMessage);
}

session.AddAttempt(challengeCreationResult.Data);

在创建确认尝试并收到挑战之后，用户可以提交他的响应以进行验证。

var session = await _sessionStore.GetAsync(sessionId);

var result = await session.ApplyResponseAsync(response, _responseValidator, actingUserId, operationType);

AddAttempt 和ApplyResponseAsync 都会触发相应的事件，并将操作结果返回给用户。

出了什么问题

在我尝试添加需要了解多个确认会话的业务规则之前，我对此实现感到满意。它们是：

如果用户在一小时内对单个操作类型给出了五个错误的答案，我们需要冻结他一小时。
如果自上次 Confirmation Attempt 后 30 秒没有正确答案，用户只能请求新的 Confirmation Attempt。

问题

如何在保持聚合根/服务/事件处理程序小而专注的同时实施这些规则？

【问题讨论】：

标签： c# domain-driven-design cqrs event-sourcing

【解决方案1】：

我认为UserConfirmation 作为一个聚合看起来不错，但不是UserConfirmationHistory 的想法，因为不建议有很多孩子的聚合，这里就是这种情况。

在这种情况下，业务规则自然不适合聚合，应该向上移动到域服务，该服务可以在应用服务提供的UserConfirmation 实例列表上运行。

我的意思是，我不喜欢在我的域类中存在任何基础架构问题（无论是聚合还是服务），并且获取 UserConfirmation 条目列表需要查询或存储库实现，这是基础架构问题，即使您确实使用接口将它们抽象出来。

我会做什么

应用程序服务：持有对IUserConfirmationRepository 的引用并获取UserConfirmation 条目的列表，并将它们传递给...
域服务：将接收UserConfirmation 条目列表并验证跨越多个聚合的逻辑

这样，您的业务规则仍然受到域类的保护。

但是谨慎行事：

通过这种方式，您可能刚刚打开了一个漏洞。如果您的代码的用户能够创建和保留 UserConfirmation 实体的实例而无需通过此域服务，那么他们将能够绕过此不变量；
那么你应该想办法阻止它。也许通过在 UserConfirmation 聚合中创建构造函数 internal，并使其创建此聚合的唯一可能路径是通过域服务。

PS。你提到当你只需要做简单的 INSERTS 时事情会更容易，但是：

DDD 并非适用于所有项目。在使用 DDD 的项目早期会有很多摩擦，只有在您的领域非常复杂的情况下，这才是合理的。然后，您将在未来获得利益；
如果 DDD 确实是该项目的正确方法，那么以后您将真正受益于这种方式

【讨论】：