Diseño de n niveles con sitio web y procesador de transacciones de fondo

Question

Tenemos un sitio web, donde las transacciones se ingresan y pasan a través de un flujo de trabajo. Vamos a seguir el estándar BLL (Business Logic Layer), DTO (Data Transfer Object), DAL (Data Access Layer), etc. para una aplicación escalonada. Tenemos la necesidad de separar todo porque algunas transacciones cruzarán múltiples aplicaciones con diferente lógica de negocios.

También tenemos un procesador de back-end. Maneja nuestras transacciones una vez que se ha completado el flujo de trabajo. Funciona con varios sistemas de terceros, algunos de los cuales son inestables o la interfaz con ellos es inestable, y luego informa el estado de la transacción. Cada sitio web tendrá su propia versión del procesador de fondo.

Ahora la pregunta, con N-Tier, sugieren un nuevo BLL para cada aplicación. Con el diseño de la aplicación anterior, se puede argumentar que el procesador de back-end y el sitio web es una aplicación que actúa al unísono, o dos aplicaciones con lógica empresarial diferente. ¿Cuál sería la forma ideal de manejar esto? ¿Ha actuado como un sistema o dos?

Answer 1

Una cosa que aprendí mientras aprendía MVC en los últimos dos años es la diferencia entre lo que llamo lógica de aplicación y lógica de dominio. Ya no me gusta el término lógica de negocios, porque tiene demasiado bagaje de todas las teorías y prácticas en conflicto que han usado ese término demasiado libremente.

La lógica de dominio es la " tradicional " lógica empresarial, cómo se supone que deben actuar las cosas, qué requieren (validación), etc. La lógica de la aplicación es cualquier cosa que sea específica para una presentación determinada de su dominio, es decir, cuando el usuario hace clic en este botón de envío en su aplicación web, se les dirige a esta página web aquí (tenga en cuenta que esto no tiene nada que ver con cómo funcionaría una aplicación WinForms o un procesador en segundo plano). La lógica de la aplicación debe vivir en su aplicación. La lógica de dominio debe vivir en su BLL y versiones inferiores, y ser reutilizable en las diferentes aplicaciones que pueden usar su "lógica de negocios" común.

Como una respuesta general, pero espero que ayude.

Answer 2

Puede considerar dividir la funcionalidad para reflejar la organización de las partes interesadas. Por lo general, si tiene dos grupos organizativos distintos, los requisitos de desarrollo y administración son más fáciles de administrar si la funcionalidad se divide de manera similar. Y viceversa.

La mayoría de nosotros no pasamos tanto tiempo escribiendo aplicaciones que exploren los límites externos de las capacidades de hardware y software.

Answer 3

Si separa bien sus inquietudes, creo que podrá verlas como la misma aplicación con una sola capa de lógica de negocios, no tiene sentido escribir el mismo código dos veces. El truco será forzar la separación de preocupaciones entre las partes de la interfaz de usuario del sitio web y la lógica de negocios en su biblioteca BLL.

El rendimiento también será un problema, debe asegurarse de que el procesamiento por lotes no impida que su sitio web realice las tareas que debe realizar debido a sus recursos. Esto puede ser un argumento para mantenerlos más separados, sin embargo, ya que es probable que compartan una base de datos de todos modos (o algún otro recurso basado en archivos), entonces eso puede ser un problema independientemente.

Mantendría una biblioteca lógica de negocios común programada para interfaces y completamente separada de sus otras preocupaciones.

Answer 4

El " Ideal " La forma de hacerlo depende del proyecto en cuestión y de los diversos requisitos del sistema.

Mi diseño predeterminado es que actúe como una sola aplicación. Pero si se están llevando a cabo más procesos pesados, me gusta crear un proceso de procesamiento por lotes donde los parámetros del trabajo solicitado se almacenan y actúan mediante un proceso separado.