I'm going to set out a scenario/pattern I've encountered and then I have a few questions pertaining to it.During an MVC request in a web framework (PHP, Laravel in my case), if I have an abstract base class Service where subclasses:Do not return valuesDeposit the result of their work into a common Response singleton, even across multiple service classes.Never throw exceptions but instead report error situations as another bag of values in the response singleton.Offer a fluent API to chain calls to a single Service subclass.When a caller (controller) does finally want data, they terminate the fluent API with a getResponse() method which returns the Response singleton, with no idea of what might be in it or what transpired and when over the course of the prior chained calls.Would I have an anti-pattern on my hands here?  My concerns being:Service subclasses now hide the data they return in a generic bag of data - ResponseBecause of the desire to implement a fluent API, services are now more or less a relocation of controller code, rather than portable business logic. In order to do fluent calls, the methods all have to exist on the same instance which means you are now forced to mix unrelated functionality into the same instance.Callers of a service class (typically controllers and other services) are now coupled to the structure of the Response class, rather than being provided with the data they request (say an ORM collection, or a simple language collection type), they're now having to perform extra work rather than simply deal with pure, returned data.Separation of concerns when creating inter-dependent services, especially during error situations whereby the scope of the failure is lost.Loss of the ability to detect accidental circular dependencies between services via dependency injectionIs this SOA?Are there any more risks in this design or if it's a known one, are there advantages to this pattern over simply writing plain classes that return the domain data directly for a service layer?
Is this any form of service pattern, some other pattern, SOA or just an anti-pattern?
mvc;soa;anti patterns;service