¿Cómo separar limpiamente las diferentes partes de una aplicación de software?

Estoy diseñando una nueva aplicación que maneja mucha lógica de negocios.

Para evitar el enredo habitual entre las diferentes capas de aplicación que a menudo se infiltra en dichos sistemas con el tiempo, quiero implementar una separación limpia de las preocupaciones desde el principio. En términos generales, quiero separar:

Capa de presentación
capa de lógica de negocios
almacenamiento de datos y capa de persistencia

La pregunta con la que más estoy luchando es cómo implementar realmente el comportamiento en los bordes de manera limpia, especialmente entre el negocio y la capa de datos. He visto demasiadas aplicaciones en las que la capa de datos entrega objetos ORM a la capa central, acoplando de manera efectiva la lógica empresarial al ORM.

¿Debo convertir los objetos ORM a algún formato serializado (JSON?) Y luego deserializar eso en la capa empresarial en una estructura de datos interna a esa capa? ¿No es eso mucha sobrecarga?

¿Cómo implementar limpiamente la separación de preocupaciones para aplicaciones de tamaño mediano? ¿Algún consejo?

design separation-of-concerns modularization

— BM
fuente

¿Qué son los objetos ORM? Un ORM normalmente asigna datos a objetos de dominio que no están estrechamente acoplados a la capa de acceso a datos, por lo que no debería haber ningún problema en pasarlos a la capa empresarial. Por supuesto, la infraestructura ORM en sí misma no debe pasar a la capa empresarial.

— JacquesB

Veo muchas clases de generación automática de ORM que asignan el esquema de base de datos 1: 1, por ejemplo article.getId(), article.getTimestamp()etc. Estas asignaciones parecen ser más frecuentes que las específicas de ORM utilizadas.

— BM

Probablemente deberías cambiar ORM. ¿Qué ORM estás usando?

— JacquesB

Todavía no he decidido un ORM para este proyecto, pero he trabajado con algunos: SQLAlchemy, SQLObject, Django ORM, Propel, ...

— BM

Encontrará sugerencias detalladas sobre esto en la descripción del tío Bob de una arquitectura limpia . Los párrafos "cruzando límites" y "Qué datos cruzan los límites" se refieren exactamente a su problema.

— Doc Brown

Respuestas:

Siempre hay una especie de acoplamiento lógico entre la lógica empresarial y la base de datos. Sus esfuerzos deben centrarse en prevenir un acoplamiento físico .

Por ejemplo, tome la regla comercial muy básica de que cada usuario debe tener un ID de usuario único. Puede intentar aplicar esa regla en la capa empresarial, pero siempre habrá algún escenario en el que varios usuarios puedan probar la misma ID de usuario al mismo tiempo, y el único lugar donde puede verificar la unicidad y reservar una ID de usuario en un La forma atómica está en la base de datos.

Ahora, la capa empresarial no debería necesitar saber el nombre de la tabla o la columna, o incluso que los usuarios están almacenados en una base de datos (podrían, por ejemplo, almacenarse en Active Directory, para una aplicación de intranet). Solo la capa de acceso a datos debe saber eso. Pero gastar un montón de esfuerzo desconectando el esquema de las reglas comerciales es probablemente un esfuerzo desperdiciado.

— John Wu
fuente

guids han estado alrededor por un tiempo ahora

— Ewan

Asegúrese de que los objetos de su modelo de negocio estén en su propia biblioteca que no haga referencia a ningún cliente ORM o de base de datos.

Utilice el patrón de repositorio y solo haga referencia a las interfaces de los repositorios en su código principal.

Tenga una biblioteca de repositorio concreta completamente separada específica para la capa de datos que hace referencia a la biblioteca de interfaz, la biblioteca de modelos de negocio y el cliente de la base de datos.

— Ewan
fuente