问DDD模式中服务“帮助类”的单元可测试约定

EN

我对Java相当陌生，我加入了一个利用DDD模式(据说)的项目。我来自强大的python背景，对单元测试驱动的设计相当深入。也就是说，迁移到Java的挑战之一是服务层的可测试性。

我们的REST类项目堆栈如下所示：

• ServiceHandlers，它处理请求/响应等，并调用IService的特定实现(例如。DocumentService)
• DocumentService --使用makeOwner(session, user, doc)等方法处理审核、权限检查等。

目前，类似于DocumentService的东西有通过guice注入存储库依赖项。在像DocumentService.makeOwner这样的公共方法中，我们希望确保会话用户是管理员，并检查目标用户是否已经是所有者(利用注入的存储库)。这就产生了一些欺骗代码--一个用于解决用户问题并确保成员资格、权限等的两个用户。为了消除这些冗余代码，我想要进行一种超级简单的isOwner(user, doc)调用，可以简洁地模拟各种测试场景(例如，当用户无法解析时抛出异常等)。这是我搜索失败的地方。

如果我将它放在与DocumentService相同的类中，那么在同一个类中测试makeOwner时(由于Mockito的限制)，我不能模拟它，尽管它感觉应该放在这里(option1)。

如果我把它放在像DocumentHelpers这样的低级类中，感觉有点滑稽，但我可以轻松地模仿它。此外，DocumentHelpers还需要注入存储库，这在guice中是很好的。(备选案文2)

我要补充的是，在我们的幼稚代码库中有许多这样的点是不可测试的，因为方法不是静态地调用相同的* ServiceHandler类中没有使用的类似助手的方法。然而，在这个阶段，我不知道这是糟糕的设计还是仅仅是好的。

因此，我询问更有经验的Java开发人员：

1. 引入“服务助手”似乎是一个有效的解决方案吗？
2. 这是DDD负责人的柜台吗？
3. 如果没有，除了“帮助者”之外，是否还有更多的DDD友好命名约定？

增加3位bits：

• 我的googling大部分都是关于“帮助者”的争论，因为它是用于无状态操作的静态实用方法，比如日期格式，这不适合我的问题。
• 我不想使用PowerMock，因为它破坏了代码覆盖率，而且使用起来很难看。
• 在python中，我可能会将上面描述的"Service“层称为internal_api，但这在Java中似乎有不同的含义，特别是因为我需要公开类来对它们进行单元测试。

如有任何指导，将不胜感激。