MantenimientoWeb Enterprise Resource Planning (ERP) MVC - Manejo de Sistema Inventario (Inventory Management System)

Enlace para la página: http://mantenimientoweb.somee.com/

Table of contents

Sobre el proyecto

Características del proyecto

Funciones

Proceso del diseño de la arquitectura de la aplicación

Estructura

Capa de Dominio o Core

Capa de Aplicación

Capa de Infraestructura

Capa de Presentación

Capa de Pruebas - no hay contenidos, pero sirve para futuro uso**

Sobre el proyecto

-Fecha de creación del proyecto: 23 de Agosto 2024 - 12 de Septiembre 2024
-Lenguajes de Programación: C#, HTML, CSS, JavaScript, JQuery, bootstrap, SQL Server
-Entorno de Trabajo: Visual Studios 2022, ASPNET MVC 6, .NET 6, SQL Management Server Studio
-Descripción: Se trata de una simple aplicación de planificación de recursos empresariales (Entreprise Resource Planning) para un sistema de manejo de inventarios (Inventory Management System).

---

Características del proyecto

-Dashboard: Organiza y facilita la navegación en las distintas entidades y funcionalidades del proyecto.
-CRUD Operations: Permite el usuario para crear, ver detalles, actualizar, y eliminar datos en el proyecto.
-Busqueda: Permite el usuario hacer una busqueda de lo que desea buscar.
-Arquítectura: Onion o Clean Architecture/ Arquitectura Por Capas.
-Metodología del desarrollo: Agile Development

---

Funciones

-Entidades: Empresa, Producto, Inventario
-ViewModels: Sirve para validar los inputs del usuario (filtración de datos) antes de pasar a los business models (entidades)
-Repositorios y Servicios: Sirve para guardar los métodos para la obtención de datos y las operaciones CRUD antes de pasar a los Controllers (necesitara Dependecy Injection para usar repositorios y servicios).

---

Fases o Proceso del diseño de la arquitectura de la aplicación

📚Aprendizaje: Guía de Arquitectura N-Capas Orientada al Dominio con .NET 4.0

1ª Fase: Identificación de los Objetivos de Iteración --Iteración 1--

Objetivos Identificados de Iteración:

Creación de la entidad de productos y la relación con categorías y proveedores(empresa): Informara el sistema si se puede empezar almacenar información básica sobre los productos. Sin un SOLID principle para gestionar los productos, no se puede avanzar en otras funcionalidades como la creación de la entidad de Inventario.

Diseñar la interfaz para el registro de productos:Creación de interfaz para que los usuarios pueden registrar productos, asignarles categorías y asociarlos con proveedores.

Implementar la lógica de negocio para validación de datos: En mi caso, antes de pasar las entidades y registrar datos en la base de datos, he creado ViewModels para hacer los "business logics" y "business validations" y luego aplicarlos en las entidades a partir de un mapeo de ViewModels a Entidades o viceversa (también se puede hacer con un AutoMapper).

Establecer la infraestructura de la base de datos: configuration de connection strings para conectar con SQL Server y crear las primeras tablas necesarias como Empresas, Productos, etc. ya que el sistema necesita una base de datos para poder almacenar y gestionar la información desde las primeras iteraciones. Si el Entity Framework se trata de Table-First, las tablas se pueden crear dentro de SQL Management Studio y se trata de Code-First se hacen migraciones dentro del ApplicationDbContext/Consola de Nuget Package Manager

2ª Fase: Seleccionar los casos de uso (Use Cases) arquitecturalmente importantes

En mi proyecto he utilizado Use Cases o Casos de Usos en forma de GetQueries o queries para hacer una lectura o consultas.

Podría integrar más casos de usos en el proyecto como la Gestión de Usuarios (Autenticación y Autorización), Gestión de Pedidos, Generación de Reportes, Notificaciones y Alertas, Gestión de Roles y Permisos, Carrito de Compras, etc. pero estos elementos son para un proyecto de gran escalabilidad y complejidad.

3ª Fase: Realizar un esquema del sistema

En esta fase he decidido qué tipo de aplicación iba a desarrollar. Y esto dependerá de las restricciones de despliegue, de conectividad, de lo compleja que sea la interfaz del usuario y de las restricciones de despliegue, de conectividad, flexibilidad y tecnologías.

Por lo tanto, he decidido usar "aplicación web" porque llega a todo tipo de usuarios, tiene una interfaz de usuario estándar y multiplataforma. Además es fácil de desplegar y de actualizar.

Topología de despliegue del proyecto: "monolítico", sencillo y rápido de desplegar ya que se trata de una aplicación pequeña o simple.

Aspecto	Estilos Arquitecturales
Comunicaciones	N/A
Despliegue	Cliente-Servidor, N-Tier
Dominio	Entidades
Infraestructura	Repositorios
Interacción	Presentación Separada
Estructura	Componentes, Orientada a objetos, Arquitectura en Capas

4ª Fase: Identificación de los principales riesgos y definición de solución

Requisitos no funcionales o de calidad importantes para mitigar los riesgos y definir la solución:

La Autenticación y La Autorización	🚧In Progress/Future Work
Cacheo de datos y Mantenimiento del estado	✅
Gestión de la configuración	✅
Acoplamiento y la cohesión	✅
Acceso a datos	✅
Gestión de excepciones	✅
Registro de eventos	✅
Instrumentalización de sistema	✅
Experiencia de Usuario	✅
Validación de información	✅
Flujo de los procesos de negocio del sistema	✅

En esta face he hecho un plan de requisito o una serie de decisiones sobre los puntos clave. Por ejemplo en el cacheo de datos, he tomado decisiones qué tecnologías iba a utilizar.

5ª Fase: Creación de arquitecturas candidatas

Una vez realizados los pasos anteriores, tendremos una arquitectura candidata que podemos evaluar. Si tenemos varias arquitecturas candidatas realizaremos la evaluación de cada de ellas e implementaremos la arquitectura mejor valorada. Cualquier arquitectura candidata debería responder a las siguientes preguntas: 1- ¿Qué funcionalidad implementa? 2- ¿Qué riesgos mitiga? 3- ¿Cumple las restricciones impuestas por el cliente? 4- ¿Qué cuestiones deja en el aire?

6ª Fase: Aspectos de Domain Driven Design

---

Ejemplo de un Plan de Cuestionario para el Diseño de la Arquitectura de una Aplicación Web

1ª Fase: Identificación de los Objetivos de la Iteración

¿Cuáles son los objetivos estratégicos y tácticos de la iteración?

-Definir claramente los objetivos a nivel de negocio y técnicos.

¿Cómo se alinea esta iteración con la visión y misión del proyecto?

-Asegurarse de que los objetivos están en consonancia con la visión general del proyecto.

¿Qué métricas se utilizarán para evaluar el éxito de esta iteración?

-Establecer KPIs claros y medibles.

¿Qué stakeholders están involucrados y cuál es su papel en la definición de objetivos?

-Identificar todas las partes interesadas y su influencia en los objetivos.

2ª Fase: Selección de los Casos de Uso Arquitecturalmente Importantes

¿Qué casos de uso son críticos para el éxito de la arquitectura?

-Determinar los casos de uso que tienen un impacto significativo en la arquitectura.

¿Cómo afectan estos casos de uso a los requisitos no funcionales como rendimiento, seguridad y escalabilidad?

-Evaluar el impacto en aspectos no funcionales.

¿Qué prioridades se deben establecer para estos casos de uso en función de su impacto y complejidad?

-Clasificar los casos de uso según su importancia y dificultad.

3ª Fase: Realización de un Esquema del Sistema

¿Qué componentes clave deben estar presentes en el esquema del sistema?

-Definir los módulos y capas esenciales.

¿Cómo se deben diseñar las interacciones entre los componentes para maximizar la eficiencia y la cohesión?

-Especificar las interfaces y protocolos de comunicación.

¿Qué tecnologías y herramientas se utilizarán y por qué?

-Evaluar y justificar la selección de tecnologías.

4ª Fase: Identificación de los Principales Riesgos y Definición de Solución

¿Qué riesgos técnicos, operacionales y de negocio están asociados con la arquitectura?

-Identificar riesgos potenciales en todas las áreas.

¿Cuáles son las estrategias de mitigación para cada riesgo identificado?

-Definir medidas preventivas y correctivas.

¿Qué plan de contingencia se implementará en caso de que los riesgos se materialicen?

-Establecer planes de acción y asignar responsabilidades.

5ª Fase: Creación de Arquitecturas Candidatas

¿Cuántas arquitecturas candidatas se han desarrollado y cuáles son sus características principales?

-Documentar y comparar múltiples opciones.

¿Qué criterios se han utilizado para evaluar y seleccionar la arquitectura óptima?

-Definir criterios como costo, rendimiento, escalabilidad y mantenibilidad.

¿Cuál es la arquitectura seleccionada y qué justificaciones respaldan esta elección?

-Detallar la arquitectura elegida y la razón detrás de la selección.

6ª Fase: Aspectos de Domain Driven Design

¿Cómo se han identificado y modelado los dominios y subdominios?

-Aplicar principios de Domain Driven Design para definir dominios y subdominios.

¿Qué entidades y agregados se han definido y cómo se gestionan sus relaciones?

-Especificar entidades clave, agregados y sus interacciones.

¿Cómo se han definido y aplicado los límites de contexto y las interfaces entre ellos?

-Detallar los límites de contexto y las estrategias para la integración entre ellos.

---

Estructura/Arquitectura: Capa de Dominio o Core

La capa más interno del proyecto. Aquí almacenemos las entidades que vamos a usar en el proyecto.

-Referencia: N/A

---

Estructura/Arquitectura: Capa de Aplicación

Aquí almacenemos los DTOs, Servicios de Aplicación, Use Cases, etc.

-Referencia: Capa de Dominio o Core

---

Estructura/Arquitectura: Capa de Infraestructura

Aquí almacenemos los repositorios, sus interfaces, datos para la base de datos, ApplicationDbContext, etc.

-Referencia: Capa de Aplicación y Capa de Dominio o Core

---

Estructura/Arquitectura: Capa de Presentación

La capa más externa del proyecto. Aquí almacenemos los Controllers, ViewModels y Models, Views, Partial Views, Contents (css,js, jqueries, bootstraps), etc.

-Referencia: Capa de Aplicación, Capa de Infraestructura, Capa de Dominio.