es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

  • es.davy.ai/
  • Programación /
  • En la arquitectura del tío Bob, al cargar una entidad que no es de la base de datos, ¿siempre se carga la totalidad de la entidad?

En la arquitectura del tío Bob, al cargar una entidad que no es de la base de datos, ¿siempre se carga la totalidad de la entidad?

27 Jul, 2023 Programación

Contexto:

Uncle Bob tiene un ejemplo llamado el ejemplo de nómina. Esta página tiene un gran ejemplo descargable y un paso a paso de qué es exactamente esto: http://cleancodejava.com/uncle-bob-payroll-case-study-full-implementation/#disqus_thread.

En el ejemplo de nómina, un empleado tiene 4 clases que representan el cronograma de pago / tipo de pago / etc. (que teóricamente podrían ser de 20 tablas diferentes). Hay varios “interactors” que interactúan con cada una de estas clases. Los “interactors” utilizan un gateway para acceder al empleado a través de findById(), que devuelve un empleado cargado con las 4 clases también extraídas de la base de datos.

Pregunta:

Esto es genial en el ejemplo, pero en un sistema más grande me encuentro con algunas preguntas sobre la obtención de entidades. Se presenta un nuevo caso de uso en el que solo queremos editar el nombre de los empleados. Usar el gateway findById devuelve un empleado (¡genial!), pero también carga innecesariamente las 4 clases adicionales que son innecesarias para el interactor de actualización de nombre de empleado.

Entonces:
1. ¿Cargamos parcialmente al empleado en función del caso de uso? Esto significa que el gateway puede tener muchos más métodos de carga altamente especializados.
2. ¿Cargamos un tipo completamente nuevo de empleado simplificado? (EmpleadoNombrable) Esto implicaría muchas entidades que solo cumplen casos de uso específicos.
3. ¿La entidad “carga perezosa” otros campos según sea necesario? Esto significa que la entidad necesitaría un gateway para acceder a sus subcampos que están en otras tablas.
4. ¿Alguna otra idea de cómo podría funcionar esto?

¿O simplemente entendí mal lo que significa la entidad por completo? ¿Es esta la razón por la cual en esta arquitectura el empleado es abstracto? ¿Para que el gateway pueda devolver versiones simplificadas que aún “aparecen” como un empleado?

¡Muchas gracias!

Tags:  ,

Answer

  1. Avatar for davy.ai
    davy.ai

    Como experto en TI especializado en arquitectura de entidades y arquitectura limpia, aquí están mis respuestas a las preguntas planteadas en este contexto:

    1. Cargar parcialmente al empleado basado en el caso de uso es un enfoque viable, pero requeriría métodos de carga más especializados en el gateway. Esto puede hacer que el gateway sea más complejo y difícil de mantener con el tiempo, y es posible que no sea escalable en sistemas más grandes.
    2. Crear un nuevo tipo de empleado simplificado, como NamableEmployee, puede resolver el problema, ya que proporciona un tipo de entidad específico para el caso de uso. Sin embargo, esto potencialmente puede llevar a muchas entidades redundantes que cumplen con casos de uso específicos, lo cual también puede ser complicado de gestionar con el tiempo.
    3. La carga perezosa de otros campos según sea necesario también puede ser un buen enfoque, pero puede requerir una lógica más compleja en la entidad y el gateway.
    4. Otra opción es utilizar una combinación de carga perezosa y carga parcial basada en el caso de uso. Esto puede proporcionar una solución más flexible y escalable que puede adaptarse a los requisitos comerciales cambiantes con el tiempo.

    En la arquitectura limpia, las entidades deben representar conceptos o ideas empresariales que tengan significado y valor para el sistema. La entidad abstracta “Employee” en el ejemplo permite la flexibilidad en cómo se carga y se utiliza, lo cual puede ser beneficioso en sistemas más grandes con requisitos cambiantes. Se pueden crear versiones simplificadas de la entidad según sea necesario para representar casos de uso específicos, manteniendo al mismo tiempo un modelo de datos central coherente.

Comments are closed.