I totally agree with the assessment, as well as with the equally painful ideas for working around it.
But what would be a healthy way to address this?
Have a domain class that encapsulates the logic: if <condition>: shipOrder() where ship order is emitting an event that is captured by a wrapper/port/adapter that knows that a shipOrder event should result in the sendLocalcall?
That would make the test and the domain more clear, but the added level of indirection makes it hard to reason about the whole order lifecycle…
The alternative is passing in an interface into the domain layer and then doing some integrated tests using mocks to ensure the right method is called, but that test then becomes an “implementation test” instead of a “requirement test”…
And this doubt is what creates the broken window situation, the reasoning goes “Hmm, this is bad, but I don’t have any good solutions yet. I will leave it as is and come back later”
It would be great to see how others would address this!