Unit Testable convention for Service "Helper Classes" in DDD pattern

I'm fairly new to Java and joining a project that leverages the DDD pattern (supposedly). I come from a strong python background and am fairly anal about unit test driven design. That said, one of the challenges of moving to Java is the testability of Service layers.

Our REST-like project stack is laid out as follows:

• ServiceHandlers which handles request/response, etc and calls specific implementations of IService (eg. DocumentService)
• DocumentService - handles auditing, permission checking, etc with methods such as makeOwner(session, user, doc)

Currently, something like DocumentService has repository dependencies injected via guice. In a method like makeOwner, we want to ensure the session user is an admin as well as check if the target user is already an admin (leveraging the injected repositories). This results in some dupe code - one for both users involved. To eliminate this redundant code, I want make a sort of super simpleisOwner(user, doc) call that I can concisely mock out for various test scenarios. Here is where my googling fails me.

If I put this in the same class as DocumentService, I can't mock it while testing makeOwner in the same class (due to Mockito limitations) even though it somewhat feels like it should go here (option1).

If I put it in a lower class like DocumentHelpers, it feels slightly funny but I can easily mock it out. Also, DocumentHelpers needs the injected repository as well, which is fine with guice. (option 2)

I should add that there are numerous spots of this nature in our infant code base that are untestable currently because methods are non-statically calling helper-like methods in the same *Service class not used by the upper ServiceHandler class. However, at this stage, I can't tell if this is poor design or fine.

So I ask more experienced Java developers:

1. Does introducing "Service Helpers" seem like a valid solution?
2. Is this counter to DDD principals?
3. If not, is there are more DDD-friendly naming convention for this aside from "Helpers"?

3 bits to add:

• My googling has mostly come up with debates over "helpers" as static utility methods for stateless operations like date formatting, which doesn't fit my issue.
• I don't want to use PowerMock since it breaks code coverage and is pretty ugly to use.
• In python I'd probably call the "Service Helper" layer described above as internal_api, but that seems to have a different meaning in Java, especially since I need the classes to be public to unit test them.

Any guidance is appreciated.