Pregunta para los entendidos de CLEAN architecture

Axtrix #1 Oct '20 Diamond hands

Una pregunta para los entendido de CLEAN architecture y similares.

Tengo un backend montado en Typescript con mongoose y tal respetando el CLEAN architecture lo maximo posible, pero tengo una duda respecto a como extender mis repos y casos de uso.

Pongamos que tengo un repo para empleados tal que asi:

spoiler

import { mquery } from 'mongoose';
import BaseRepository from '../shared/repositories/base.repository';
import { Employee, EmployeeModel } from './employee.model';

export default class MongodbEmployeeRepository
  implements BaseRepository<Employee> {
  find = async (item?: Employee): Promise<Employee[]> => {
    return EmployeeModel.find(item);
  };

  delete = async (id: string): Promise<Employee> => {
    return EmployeeModel.findByIdAndDelete(id);
  };

  findOne = async (query: mquery): Promise<Employee> => {
    return EmployeeModel.findOne(query);
  };

  update = async (id: string, item: Employee): Promise<Employee> => {
    return EmployeeModel.findByIdAndUpdate(id, item);
  };

  create = async (item: Employee): Promise<Employee> => {
    return EmployeeModel.create(item);
  };
}

Ahora si tengo un caso de uso en el que busco un empleado por ID

spoiler

import { Employee } from '../employee.model';
import { BaseUseCase } from '../../shared/application/usecases/base.usecase';
import BaseRepository from '../../shared/repositories/base.repository';

export default class GetEmployeeById implements BaseUseCase {
  repo: BaseRepository<Employee>;

  constructor(repository: BaseRepository<Employee>) {
    this.repo = repository;
  }

  execute = async (id: string): Promise<Employee> =>
    this.repo.findOne({ _id: id });
}

¿Si tuviera que hacer un populate o una projeccion de Mongo para un caso de uso especifico donde lo haria?, ya que el caso de uso no tiene que saber nada sobre la implementacion especifica de mongodb.

¿Añado mas funciones al Repo que hagan esas queries especificas para los usecases (un poco feo) o hago esas modificacione en los casos de uso ya que realisticamente nunca vamos a migrar la base de datos de mongo a otra cosa?

Un saludo

spoiler

Yugarek #3 Oct '20

Flag en los queryparams &populate=books.
En el metodo añades la funcionalidad de si te viene el flag populate y el nombre de la tabla con la que hacerlo.

1

zoeshadow #4 Oct '20

La API del repositorio no debería exponer de ninguna manera nada sobre la implementación, es decir, que si necesitas pasar algún tipo de filtrado, sorting whatever, este debería ser genérico y que la implementación del repositorio para Mongo haga esa transformación de filtrado genérico a una query de Mongo.

Dicho esto, la otra opción es crear métodos específicos para esas queries, lo cual tp me parece mal, ya que al no exponer nada de Mongo hacía afuera te haría fácil cambiar la implementación del repo en el futuro.

1

Axtrix #5 Oct '20 Diamond hands

Vere entonce como puedo pasar un objecto de configuracion al repo y ahi mapearlo para que haga lo que quiero. Gracias a los dos

desu #6 Oct '20

Yo no he entendido la duda.

No entiendo el por que estas aplicando clean.

Empieza la pregunta explicando el porque y tu problema a resolver.

Quieres re usar ese código de mongo para muchos proyectos? (Vertical)
Mismo proyecto pero otros dominios? (Horizontal).
O ninguna de las anteriores y solo es un tema de organización de código o guía de estilo?

Depende del caso te recomiendo una cosa u otra.

Por lo que he entendido estas entre el segundo caso y como organizar código de la implementación/caso de uso. Para lo último lo que dice el ninya.

1 respuesta

Axtrix #7 Oct '20 Diamond hands

#6 tengo una buena paja mental en estos momentos momentos, pero más o menos:

Estoy usando CLEAN porque es un projecto para la empresa que se va a extender bastante y va a haber varios pajeets como yo tocando el codigo, asi que habia que estandarizar un poco la forma en la que trabajamos.

La cosa es que mis repos son muy generales y algunos de mis casos de uso requiren usar projecciones, .populate() y .lean() en la query del repositorio.

Entonces tenia la duda de como lidiar con estos casos especiales, puedo saltandarme un poco el CLEAN architecture en esos casos de uso, o puedo extender el repo para que exporte una funcion especifica para cada caso de uso

1 respuesta

s4suk3 #8 Oct '20 Penitente

-> backend > ts
-> clean

1 respuesta

Axtrix #9 Oct '20 Diamond hands

#8 pasapalabra

JuAn4k4 #10 Oct '20

Echale un ojo a CQRS, para mi es lo de siempre, tener algo genérico está bien si vas a hacer CRUD y ya, pero si quieres algo más, yo no tiraría por nada genérico y haría las queries separadas por dominio y por use-case.

1 respuesta

desu #11 Oct '20

#7 Es un detalle de implementación de la persistencia para mongo, por tanto extendería el adaptador/repositorio añadiendo funciones que acepten por parámetro los populate/lean y lo compondría dentro de este adaptador si lo utilizaran muchas entidades.

No tengo ni idea de mongo, he googleado un poco lo que dices y me parece que esto es lo mas sencillo y simple. Si no es el caso pues lo siento, pero valdria para otros casos.

// La funcion del crud que te expondra mongo por defecto...
function findById(id: Id) {

}

// Extenderia a;adiendo una donde le paso la funcion de alguna manera 
// P.e para el caso de lean
function findById(id: Id, strategy: function) {
  findById().strategy()
// findById().lean()
}

La otra alterantiva sobre escribir los metodos de la interficie y pasar el parametro opcional, pero mejor si a;ades una funcion extra.

Es esto lo que quieres? como te digo no me parece un problema de arquitectura llegados al punto de implementar el caso especifico xd

Esto que dices es muy especifico de mongo, si esto fuese a nivel de persistencia (mongo, psql, dynamo, lo que quieras) entonces tendrías una capa extra para hacer estas composiciones.

#10 Over kill.

1

Pregunta para los entendidos de CLEAN architecture

Usuarios habituales

Tags