Arquitectura limpia: demasiadas clases de casos de uso

Voy a Arquitectura limpia y elevo mi nivel de Android de MVC a MVP , introduciendo DI con Dagger 2, Reactividad con RxJava 2 y, por supuesto, Java 8.

En la arquitectura limpia de MVP hay una capa entre las entidades (en los almacenes de datos) y los presentadores que deberían acceder a ellas. Esta capa es el "caso de uso" . Un caso de uso es idealmente una interfaz, que implementa UNA operación en UNA entidad.

También sé que Clear Architecture " está gritando ", en el sentido de que sus proyectos son realmente muy legibles debido a la gran cantidad de clases en ellos.

Ahora, en mi proyecto, tengo algo así como 6 entidades diferentes y, por supuesto, cada repositorio de entidades tiene al menos 4 métodos (generalmente obtener, agregar, eliminar, actualizar) para acceder a ellos ... entonces, 6 * 4 = 24 .

Si lo que entendí hasta ahora de Clean Architecture, tendré 24 UseCase.

Estas son muchas clases si se comparan con solo 6 controladores en MVC.

¿Realmente tengo que hacer 24 casos de uso?

Realmente apreciaré una aclaración de alguien que ya la usó con éxito.

Gracias Jack

— Jackie Degl'Innocenti
fuente

¿Puede publicar un enlace a una página que describa estos casos de uso en detalle, con un código de ejemplo?

— Robert Harvey

He buscado mucho en Google, pero principalmente: esta muestra de aplicación y artículo relacionado: github.com/jshvarts/OfflineSampleApp ; estos artículos: proandroiddev.com/… ; proandroiddev.com/… ; Esta charla: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Y estos artículos también: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Ninguna de las aplicaciones o artículos de muestra que citó parece tener mucho que ver con Clean Architecture. Sin embargo, hablan mucho sobre programación reactiva.

— Robert Harvey

La aplicación de muestra seguramente está hecha con el paradigma de Clean Architecture. Los otros artículos en su mayoría ... ¿Qué quieres ver en @RobertHarvey?

— Jackie Degl'Innocenti

Lea mi respuesta a continuación y responda.

— Robert Harvey

Respuestas:

¿Realmente tengo que hacer 24 casos de uso?

Solo si todo lo que escribes es CRUDO .

Hacer referencia al diagrama de abajo:

Su afirmación es que tendrá seis entidades diferentes y 4 métodos (Crear, Leer, Actualizar y Eliminar) para cada entidad. Pero eso solo es cierto en el círculo amarillo en el medio del diagrama (la capa Entidades). No tiene sentido crear 24 métodos en la capa de Casos de uso que simplemente pasan a través de llamadas CRUD a la capa Entidades.

Un caso de uso no es "Agregar un registro de cliente". Un caso de uso es más similar a "Vender un artículo a un cliente" (que involucra entidades de Cliente, Producto e Inventario) o "Imprimir una factura" (que involucra a las mismas entidades, además de Encabezado de factura y Líneas de factura )

Cuando crea casos de uso, debe pensar en transacciones comerciales, no en métodos CRUD.

Agregado de lectura adicional
: un grupo de objetos de dominio que se pueden tratar como una sola unidad

— Robert Harvey
fuente

Estás pasando demasiado tiempo pensando en patrones, prácticas y arquitectura, y no tienes suficiente tiempo pensando en el diseño de software básico. Todo lo que necesita son métodos que incorporen prácticas comerciales, como describí en mi respuesta.

— Robert Harvey

No se trata de elegir una arquitectura. Mi opinión personal: las operaciones CRUD desnudas deberían hablar directamente con la capa de entidad. Por supuesto, esto probablemente viola la arquitectura limpia.

— Robert Harvey

Te estás perdiendo el punto. La arquitectura es solo un medio para organizar el código. Resuelve problemas escribiendo código, no luchando con arquitecturas.

— Robert Harvey

Hola Robert, no es tan agradable que asumas que no escribo código. El tema de mi respuesta es sobre arquitectura, y no estamos en SO. Sinceramente, encuentro sus últimos comentarios realmente engañosos y sordos. La pregunta es acerca de UseCase en Clean Arch., No escribir código. Si está tratando de comunicar algo, explique mejor, porque me estoy perdiendo el punto de sus comentarios. En mi humilde opinión, no es posible evitar la consideración de la arquitectura al desarrollar software, o al menos, los buenos desarrolladores no solo escriben un montón de código. Además, hice una pregunta realmente específica en mi comentario, ¿puedes responder? Gracias

— Jackie Degl'Innocenti

La solución al problema que planteaste (la aplicación fuera de línea primero) realmente no tiene mucho que ver con Clean Architecture. No encontrará una solución a ese problema en el diagrama de Arquitectura limpia.

— Robert Harvey

Tiene razón si cada Operación CRUD se traduce en un UseCase. Pero un UseCase también puede consistir en múltiples operaciones CRUD.

UseCase es un modelo separado que reúne información de diferentes fuentes de datos y prepara la comunicación para los sumideros de datos. Puede haber múltiples operaciones CRUD involucradas.

Entonces, piense en un UseCase donde se crea una factura para un cliente Y también se crea el cliente mismo porque él / ella no existe dentro del sistema. Tiene un UseCase que resulta en al menos dos Operaciones de creación en una transacción.

— oopexpert
fuente

Entonces, ¿qué patrón recomendaría para el ejemplo de CRUD con muchas entidades?

— Jackie Degl'Innocenti

Mi opinión personal sobre esto es: no tengo ningún problema para tener muchas clases, siempre y cuando no violen SRP (principio de responsabilidad única). Pero la mayoría de las veces redefiniría los Casos de uso "crear una entidad", "actualizar una entidad", "eliminar una entidad" y "actualizar una entidad" a una simple "entidad de gestión de tipo X". A menudo, proporciona una única interfaz de usuario para administrar una entidad. Pero eso es exactamente lo que su UseCase debería definir: la forma de manejar una carga de trabajo beneficiosa para su negocio.

— oopexpert

Ok, entonces, tener un caso de uso que maneja varias operaciones diferentes no parece violar SRP ya que parece "agregar" más métodos (y flujos) diferentes en el mismo UseCase sin que ningún flujo individual maneje más de una responsabilidad. ... pero de esta manera, ¿no estamos simplemente creando un controlador en lugar de un UseCase? ... idea ... Tal vez el caso de uso debe verse simplemente como una capa, y esa capa solo tiene que respetar SRP pero también puede implementar muchos métodos. Me gustaría tener una fuente o artículo sobre esto

— Jackie Degl'Innocenti

Un caso de uso es un controlador. La única diferencia es que un caso de uso proviene de la perspectiva comercial y un controlador es la visión técnica sobre él. El enfoque de un caso de uso es, lo que está generando el valor comercial. Por lo tanto, un caso de uso es una implementación de controlador impulsada por el valor empresarial.

— oopexpert

De acuerdo, un controlador HTTP es una forma de administrar E / S, también puede haber comandos de consola, reacciones de eventos, etc. Todos estos canales de E / S llaman al mismo caso de uso. Un caso de uso ES un controlador para la lógica de negocios, no conoce los canales de E / S desde los que se llamó, pero sabe cómo orquestar entidades de dominio para hacer el trabajo.

— Dmitriy Lezhnev

Su definición de caso de uso es incorrecta, el caso de uso es una clase que implementa una regla de negocio, no necesita ser una operación CRUD, puede ser una operación compleja de varios pasos

— Buckstabue
fuente

Su oración no significa una solución cuando realmente necesita implementar una amplia gama de operaciones tipo Crud, incluso su consideración puede encontrar alguna relación con el hecho de que un caso de uso debe observar un patrón en el que podríamos acceder a una operación compleja, Incluso múltiples pasos.

— Jackie Degl'Innocenti