¿Me estoy cargando el Single Responsability?

[Víctor Garcia Merediz]

Hola,

Quiero crear una Application Service que gestiones las llamadas a una API que tengo. Lo estoy creando tal que así:

class ApiService
{
    private $client;

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

    public function industries()
    {
        $this->client->request(getenv('API_URL') . '/industries');
    }


    public function createIndustry()
    {
        $this->client->post(getenv('API_URL') . '/industries');
    }

    public function categories()
    {
        $this->client->request(getenv('API_URL') . '/categories');
    }

    public function offers()
    {
        $this->client->request(getenv('API_URL') . '/offers');
    }
}

Me estoy cargando con esto el principio Single Responsability? Debería crear una ApiServiceIndustry, ApiServiceCategory, ... ?

[Michael-Jorge Gómez Campos]

Purísticamente hablando sí, sería mejor que cada servicio estuviera empacado en su propia clase. Ahora bien, si esto es lo que necesitas tampoco hay que obsesionarse. Si trabajas con un equipo, habladlo y elegid la manera que os sea más clara. Si en el futuro véis que para algunos métodos tenéis que trampear, pues ya es el momento de separar.

[Víctor Garcia Merediz]

Gracias por tan rápida respuesta! :D

Ya me imaginaba que iban a ir por ahí los tiros.

[Michael-Jorge Gómez Campos]

Me has pillao asi de suerte XD sobre el tema del SRP, es uno de esos principios que si no tienes MUY claro el cómo aplicarlo y el beneficio que consigues al aplicarlo, más vale que hagas como has hecho y tenerlo en un único sitio. Siempre "estarás a tiempo" de separarlo cuando ya no tengas ninguna duda.

[Pepito Fernandez]

Aun no me queda claro algo. Este servicio quien lo usa? Tu dominio? Si es asi, recuerda que ahi es donde el concepto de "Anti-Corruption Layer" or capa de anticorrupcion es donde vive. Si esos "modelos" que estas recibiendo desde "afuera" no son "convertidos" a agregados o entidades de tu dominio, entonces estas corrompiendo tu dominio. Ahi es donde es importante pensar en el SRP.

La idea es crear servicios individuales que consuman otros servicios y conviertan el objeto que recibe en otro que tenga sentido en tu dominio. Si tuvieras todas las llamadas bajo un solo servicio, entonces tendrias que modificar esa clase cada vez que tengas que cambiar cualquier logica relacionada con los modelos que maneja. Tiene sentido?

Digamos que tu modelo 'industries' ha cambiado y necesitas cambiar tu servicio para satisfacer ese nuevo cambio. No existe razon para que cambie otro codigo en tu servicio. Bueno, en ese caso te das cuenta de que los puedes separar. Recuerda, une lo que cambia en unisono y separa lo que no.

PF

[Pepito Fernandez]

Aun no me queda claro algo. Este servicio ApiService quien lo usa? Tu dominio? Si es asi, recuerda que ahi es donde vive el concepto de "Anti-Corruption Layer" or capa de anticorrupcion. Si esos "modelos" que estas recibiendo desde "afuera" no son "convertidos" a agregados o entidades de tu dominio, entonces estas corrompiendo tu dominio. Ahi es donde es importante pensar en el SRP.

La idea es crear servicios individuales que consuman otros servicios y conviertan el objeto que recibe en otro que tenga sentido en tu dominio. Si tuvieras todas las llamadas bajo un solo servicio como ApiService, entonces tendrias que modificar esa clase cada vez que tengas que cambiar cualquier logica relacionada con los modelos que maneja. Tiene sentido?

Digamos que tu modelo 'industries', del servicio que ApiService consume, ha cambiado y necesitas cambiar ApiService para satisfacer ese nuevo cambio. No existe razon para que cambie otro codigo en tu servicio. Bueno, en ese caso te das cuenta de que los puedes separar. Recuerda, une lo que cambia en unisono y separa lo que no.

Si lo que estas creando es basicamente un wrapper para tu api, entonces asi esta bien. No necesitas mas. 

PF

On Tuesday, January 22, 2019 at 8:16:30 AM UTC-5, Víctor Garcia Merediz wrote:

[Michael-Jorge Gómez Campos]

Desde mi punto de vista (que no tiene valor jurídico XD), SRP no depende de dónde lo vayas a usar, no defines una clase/tipo como ApiAUsarPorLaCapaDeNegocio, al revés, defines una clase/tipo independientemente del lugar donde se vaya a usar. Las reglas de uso de las clases ya son reglas de arquitectura de software, un problema de más alto nivel.