关于用户行为历史的逻辑应该放在域内还是域外？

Question

假设这个写模型包含4个聚合：

应用程序需要在x天间隔内阻止/禁止任何访问过该商店的客户超过x次。

我应该把这个逻辑放在哪里？如果它应该在域层中，我应该为这个逻辑创建一个ClientStoreVisitHistory实体吗？或者我应该把这个逻辑放在域外？

任何帮助都是非常有用的。

Answer 1

您所谈论的限制显然属于问题域，应该在那里建模。我不会为此创建任何新类，而是将此逻辑放在对象StoreVisit的构造函数中。由于它直接处理对Store的访问并接受两个参数（客户端和存储），因此您不会以这种方式添加任何新的依赖项或新类，并且可以访问所有需要的信息来评估访问。

并且注意......如果您对问题域的类进行建模，我建议不要对实体的id进行建模（假设它们并且模型更清晰），以更好地指定关联并添加一些方法。你这样做的方式看起来更像是数据库设计。

更新（评论后）

如果需要多个属性（当前为clientVisitsLimit和daysIntervalForclientVisitsLimit），则单独的“StoreVisitLimitSpecification”实体是有意义的。如果您希望将来这个实体增长，将它作为一个单独的类是合理的。如果您希望当前版本稳定，那么将所有版本放在一个类中也是可以接受的。

关于以下内容：

  

StoreRecentVisitActivity实体聚合关联到   StoreVisitLimitSpecification。在StoreVisitLimitSpecification中   检查访问是否产生阻止/禁止：如果客户端产生了阻止/禁止   StoreVisit已经在x中出现了x次   然后StoreRecentVisitActivity阻止他。

• 我认为这不是一个好主意。 StoreRecentVisitActivity类完全是多余的，因为StoreVisit已经拥有访问历史记录。我们希望保持我们的域模型简单小巧
• 我肯定会避免在StoreVisitLimitSpecification中检查阻止/禁止。顾名思义，这是一个帮助器，规范类，应该是完全被动的，没有任何逻辑，只能从外部查询。因此，它本身不应对任何类型的验证负责。如上所述，我将这个逻辑放在StoreVisit构造函数中，或者最终（如果非常复杂）放在StoreVisit的单独帮助器类中。它可以通过Store类（因为它属于Store）从那里获取。

这是我对域模型的建议：

这是一个显示创建新StoreVisit的过程的序列图：

我发现它紧凑，简单，清晰。 StoreVisit保存了访问历史记录的所有数据，因此可以访问它而无需其他类依赖项。 Store保留对LimitsSpec的引用，并根据请求将其提供给StoreVisit。