Sharing logic among services

Question

I was talking with my boss recently about composing services from other services (in a Service-Oriented Architecture, if you haven't already guessed). We disagreed on some architectural principles and I'd like to find some articles to read around the subject to help the discussion.

My thesis is that injecting services into other services is fine. For example, I have no issues with doing the following:

class SomeService {

    protected $anotherService;

    public function __construct(AnotherService $anotherService)
    {
        $this->anotherService = $anotherService;
    }

    public function doSomething()
    {
        ...
        $this->anotherService->getWhatever();
        ...

        return $someObject;
    }
}

Some colleagues (and my boss) seem to think that this is not a good practice. Their hard rule is that a service cannot depend on another service, only a repository (or something in the architectural layer below it). The ramifications for this is that we have a lot of duplicate code, but they claim that something feels unclean about composing services from other services.

Are there some articles, books etc. out there that would be useful to consider?

Answer 1

Based on your problem description I think the problem is elsewhere.

If your services need to be composed in the way you describe it sounds like they don't have clear responsibility boundaries.

You may find this problem goes away if each service has only a single responsibility and the layer above them is responsible for composing them into more business-meaningful functionalities.

Answer 2

You are both wrong. Services may be composed from other services, but not in a depdendant order. Basicly there is no differance between a service, component or class. Just the way you 'link' things is different.

1. Abstract services and only use those abstractions within other Services.
2. Use SoC on Service Level and bind using (e.g.) a ServiceLocator