Service Dependencies

We have a policy of not allowing Service Layer services to talk to one another so as to prevent the development of dependencies that aren't easy to see/find.

Likewise we have an unwritten convention that each service only talks to its own repository.

Up to this point we have employed Units of Work to sit between the UI and the Service Layer to make calls to various services where some interaction requires data go to or return from multiple services.

However, I now seem to be painted into a bit of a corner. I have a service that does a fair bit of work and it will be called, potentially, not just from the Web UI, but by other process, for example, a SQL Job or a Windows Service.

The Service Layer process I'm writing needs data from other services in the Service Layer and whilst I was using the UoW that was fine even if it made the process less atomic than I would have liked.

So, moving forward, I can:

1. Duplicate the code in my UoW in another place that can be accessed by these other external services.
2. Break the rule of disallowing the Service Layer services to talk to one another so that all of the processes using my service can make a single more atomic call.
3. Ignore the convention whereby a service only talks to its own repository and have my service get the data it needs directly from any repo that contains it.

My gut feel is to go for 3 but I was wondering what was considered Best Practice' in cases like this, if there is, in fact, any Best Practice.