Convince me my unit test is not just a duplication of the business logic. Or I am testing the wrong things? If I am wrong, what's the unit test for SomeDomainService supposed to test?
The materials you want to review
Sort summary: the method you are testing here is invoked for its effects on objects other than itself. That use case is a bit off the sweet spot for unit testing (which really loves functions, safe queries on stateful objects, and unsafe commands paired with safe queries on stateful objects).
Commands dispatched to other objects are... twitchy... in tests. The tend to be much more sensitive to implementation details than the other sorts. These kinds of tests tend to be shorter lived than the query supported sort.
The useful object pattern may help mitigate some of the risk. The fact that you are trying to measure something (did this method get called) may be a code smell - trying to tell you that there is a telemetry requirement that you haven't captured yet. If you decide that's right, you replace the mock with a useful object (production code) that includes the telemtry that you need, and your unit test turns back into the more common pair-a-command-and-a-query sort.
Of course, within the tests of the useful-object, you'll be back in the same boat you are now -- a raw call to some other component that you're probably going to mock out. There's no magic, we've just shuffled the side effect (and the mock) further away from the code that you are testing.
The basic discipline here being that as you get closer to the "boundary", the implementations should approach being "so simple that they obviously have no deficiencies", at which point you stop bothering with "unit/developer" tests, and instead squeeze out that last bit of confidence using integration/system/acceptance testing.