cuándo introducir un nivel de servicios de aplicación en una aplicación de n niveles

Estoy desarrollando una aplicación basada en la web cuyo objetivo principal es obtener datos de la base de datos, mostrarlos en la interfaz de usuario, tomar las entradas de los usuarios y volver a escribirlas en la base de datos. La aplicación no va a hacer ningún algoritmo de fuerza industrial, pero recibirá un número muy alto de visitas en las horas pico (que se describen a continuación) que cambiarán a lo largo del día.

Las capas son su típica presentación, negocio, datos. El servidor de bases de datos se encarga de la capa de datos. La capa empresarial contendrá el componente DAL para acceder al servidor de base de datos a través de tcp. Las opciones que tengo para separar estas capas en niveles son:

1. La presentación y las capas empresariales pueden mantenerse en el mismo nivel.
2. La capa de presentación en un nivel separado por sí misma y la capa empresarial en un nivel separado por sí misma.

En el caso de la opción 2, la capa de presentación accederá a la capa empresarial mediante un servicio WCF a través de http o tcp.

No veo ningún procesamiento pesado en la capa Business, por lo que me estoy inclinando hacia la opción 1 anterior. También siento por la misma razón, agregar un nuevo nivel solo introducirá la latencia de la red. Sin embargo, en términos de escalabilidad en caso de que necesite escalar o escalar, ¿cuál es una mejor manera de hacerlo? Esta aplicación deberá ser capaz de soportar hasta 6 millones de usuarios por hora. Habrá una cantidad razonable de datos en cada sesión de usuario, almacenando las preferencias del usuario y otros detalles. También usaré el almacenamiento en caché a nivel de página.

Estoy de acuerdo con su evaluación inicial. Probablemente no tenga mucho sentido agregar un salto de red adicional al procesamiento de su sistema. La razón por la cual las personas separan los niveles físicamente es para su reutilización en todas las aplicaciones. Es decir, tiene varias aplicaciones que llaman a los mismos servicios para realizar una parte de su trabajo. Como mencionó, no hay mucha lógica incorporada que proporcione la capa empresarial; y hasta ahora solo hay una aplicación que lo usa.

Es bueno que haya separado los niveles lógicamente, pero una separación física en este momento podría ser exagerada.

Actualización para abordar problemas de escalabilidad

Todavía argumentaría que mantener el BLL en el mismo nivel físico que la capa de presentación es el mejor enfoque por ahora. Puede escalar agregando más nodos de presentación / bll (ya tratados si está utilizando una implementación de cliente pesado, lo suficientemente simple como para hacer con una aplicación web). Además, si descubre que la base de datos se está convirtiendo en el cuello de botella, la mayoría de las bases de datos admiten la agrupación / fragmentación y otros trucos para escalar. Solo después de haber recorrido estos dos caminos (y, por supuesto, agregar el almacenamiento en caché distribuido), consideraría agregar otro nivel físico.

Sin embargo, antes de que pueda ir allí, comenzaría a buscar crear una capa empresarial más "abundante" que una simple fachada a la capa de acceso a datos. El primer paso es considerar usar un poderoso O / RM que haga el mapeo de datos por usted. Luego considere hacer que sus objetos comerciales sean más inteligentes. Hay resmas de papel escritas en Diseño impulsado por dominio (el libro es un excelente lugar para comenzar). Seguir los pasos de modelado de dominios, definir contextos limitados y encontrar raíces agregadas lo ayudará a producir una arquitectura que tenga costuras naturales. Esto ayudará a dividir su aplicación en servicios independientes que se pueden escalar de forma independiente según sea necesario.

Supongo que está utilizando el término "nivel" para referirse a un servidor físico. Si no necesita distribuir su negocio y la capa de presentación, definitivamente lo evitaría. Enviar objetos por el cable es costoso y propenso a problemas que, de ser posible, deberían evitarse. Pero debe diseñar su arquitectura de una manera que facilite agregar más niveles a medida que el sistema evoluciona y las consideraciones de diseño justifican la distribución. Normalmente desarrollo una capa de servicio de aplicacionescomo una biblioteca / ensamblado de clase que tendría la misma interfaz que tendría su servicio WCF. Esto es lo que la capa de presentación interactúa con o con cualquier otro sistema externo. Si las capas empresariales y de presentación no necesitan ser distribuidas, entonces la capa de presentación hace referencia a la biblioteca de clases directamente. Si es necesario distribuirlos, su servicio WCF es solo una delgada envoltura alrededor de la biblioteca de clase de capa de servicio que proporciona la capacidad de acceder al servicio de forma remota.

Por lo general, es bueno vigilar el futuro, pero la introducción de una capa de Servicio, o algo realmente real, cuando no se necesita, puede ser una pérdida de tiempo ahora y ralentizar su sistema.

Dividir su sistema correctamente en capas lógicas es definitivamente algo bueno y le permitirá extender su sistema en una fecha posterior. Reducir el acoplamiento facilitará hacer esto en el futuro.

Resulta que hace un par de años trabajé en un sistema grande que era un sitio web -> capa de servicio -> todo lo demás.

La capa de servicio se introdujo porque todos los arquitectos / gerentes senior se enamoraron de SOA, por lo que nuestro sistema TENÍA que orientarse al servicio. "otros sistemas utilizarán la funcionalidad de nivel medio de nuestro sitio web" fue el grito.

Esa decisión por sí sola le costó al proyecto un año de demoras.