Skip to content

README.md

Latest commit

 

History

History
183 lines (136 loc) · 8.55 KB

README.md

File metadata and controls

183 lines (136 loc) · 8.55 KB
Raw

🐾 Ecosistema Veterinaria & Tienda de Mascotas

Solución empresarial en C# .NET 8 que demuestra la aplicación práctica de Clean Architecture, Domain-Driven Design (DDD), Event-Driven Architecture (EDA) y Patrones de Diseño GoF.

Compuesto por dos proyectos independientes: un ecosistema de 11 microservicios y una aplicación de consola interactiva como laboratorio de patrones.

📁 Estructura del repositorio

Evaluacion_2/
├── TiendaMascotas/          # Consola interactiva — OOP, Patrones GoF y DDD
│   ├── Business/            # Dominio (Entidades, Value Objects, Agregados, Eventos)
│   ├── Application/         # Casos de uso desacoplados
│   ├── Presentation/        # Interfaz de consola
│   ├── Technology/          # Repositorios en memoria y adaptadores
│   └── Program.cs
│
└── Veterinaria/             # Ecosistema de 11 microservicios
    ├── SharedKernel/        # Contratos compartidos (Caché, Event Bus)
    ├── ms-clientes/         # Puerto 8081 · PostgreSQL
    ├── ms-mascotas/         # Puerto 8082 · PostgreSQL
    ├── ms-citas/            # Puerto 8083 · PostgreSQL
    ├── ms-veterinaria/      # Puerto 8084 · PostgreSQL
    ├── ms-bano/             # Puerto 8085 · PostgreSQL
    ├── ms-productos/        # Puerto 8086 · MongoDB
    ├── ms-ventas/           # Puerto 8087 · PostgreSQL
    ├── ms-pagos/            # Puerto 8088 · PostgreSQL
    ├── ms-facturacion/      # Puerto 8089 · PostgreSQL
    ├── ms-notificaciones/   # Puerto 8090 · Redis + Kafka
    ├── ms-historial/        # Puerto 8091 · PostgreSQL
    └── infrastructure/
        └── docker-compose.yml

🏛️ Proyecto 1 — Microservicios (Veterinaria)

Arquitectura distribuida orientada a eventos (EDA). Cada microservicio tiene su propio Bounded Context y base de datos aislada (Database-per-Service).

Topología del sistema

Microservicio Puerto Base de datos Responsabilidad Patrón destacado
ms-clientes 8081 PostgreSQL Registro de dueños y datos de contacto Abstract Factory
ms-mascotas 8082 PostgreSQL Ciclo de vida y datos de mascotas Entidades de dominio ricas
ms-citas 8083 PostgreSQL Agendamiento de consultas médicas Eventos de integración asíncronos
ms-veterinaria 8084 PostgreSQL Personal médico, especialidades y horarios Validación de reglas en el dominio
ms-bano 8085 PostgreSQL Citas estéticas y tratamientos State Machine
ms-productos 8086 MongoDB Inventario y catálogo de productos Base de datos documental NoSQL
ms-ventas 8087 PostgreSQL Registro de ventas y transacciones Use Cases desacoplados
ms-pagos 8088 PostgreSQL Procesamiento de cobros Strategy para métodos de pago
ms-facturacion 8089 PostgreSQL Documentos fiscales y recibos Publicación de eventos de dominio
ms-notificaciones 8090 Redis Alertas a clientes por eventos Consumidor Kafka
ms-historial 8091 PostgreSQL Fichas médicas e intervenciones Memento — historial inmutable

Infraestructura Docker

Componente Rol
Apache Kafka + Zookeeper Mensajería asíncrona entre microservicios
PostgreSQL 9 bases de datos aisladas, una por servicio
MongoDB Almacenamiento flexible para catálogo de productos
Redis Caché de sesiones y estados temporales

🎨 Proyecto 2 — Demo OOP & Patrones (TiendaMascotas)

Aplicación de consola interactiva que funciona como laboratorio de patrones GoF, modelada con DDD y Clean Architecture.

Patrones implementados

Patrón Dónde se aplica
Factory Method CreadorMascota → CreadorPerro, CreadorGato, etc.
Abstract Factory IFactoryCliente para distintos perfiles de usuario
Builder IServicioBuilder para construir servicios de estética paso a paso
Observer Clientes suscritos que reciben notificaciones del GestorServicios
State Ciclo Pendiente → En Proceso → Finalizado sin condicionales anidados
Memento ServicioMemento para capturas de estado, auditoría y restauración
Strategy PagoTarjeta, PagoEfectivo, PagoTransferencia intercambiables en runtime

🚀 Guía de inicio rápido

Requisitos

🐳 Levantar los microservicios

# 1. Ir al directorio de infraestructura
cd Veterinaria/infrastructure

# 2. Construir y levantar todos los contenedores en segundo plano
docker-compose up -d --build

# 3. Verificar que todos los servicios estén corriendo
docker-compose ps

# 4. Probar el health check de un servicio
curl http://localhost:8081/health

# 5. Bajar el entorno cuando termines
docker-compose down

Una vez levantados, cada microservicio expone su propia UI de Swagger:

Servicio Swagger
Clientes http://localhost:8081/swagger
Mascotas http://localhost:8082/swagger
Citas http://localhost:8083/swagger
Veterinaria http://localhost:8084/swagger
Baño http://localhost:8085/swagger
Productos http://localhost:8086/swagger
Ventas http://localhost:8087/swagger
Pagos http://localhost:8088/swagger
Facturación http://localhost:8089/swagger
Notificaciones http://localhost:8090/swagger
Historial http://localhost:8091/swagger

💻 Ejecutar la consola interactiva

cd TiendaMascotas
dotnet build
dotnet run

Desde la consola podés: registrar clientes, crear mascotas con fábricas, construir servicios con el Builder, avanzar estados (State), y ver en tiempo real los Mementos y notificaciones del sistema.

📐 Principios arquitectónicos

Arquitectura Orientada a Servicios (SOA)

Principio Implementación
Contratos estandarizados Cada servicio expone su API pública vía Swagger/OpenAPI con DTOs tipados
Acoplamiento débil Comunicación por REST o eventos asíncronos en Kafka; sin dependencias en cascada
Abstracción Los detalles de persistencia (PostgreSQL, MongoDB) están ocultos tras interfaces públicas
Autonomía Cada servicio tiene su propio Dockerfile y base de datos exclusiva
Sin estado El estado persistente se delega a Redis o bases de datos externas
Componibilidad Servicios de grano fino orquestables por una API Gateway externa

Domain-Driven Design (DDD)

Patrones estratégicos

  • Bounded Contexts — cada microservicio define una frontera conceptual clara con su propio lenguaje ubicuo (Clientes, Citas, Ventas, etc.).
  • Shared Kernel — interfaces base (IDomainEvent, BaseDomainEvent) y utilidades comunes centralizadas en SharedKernel sin romper el aislamiento de los dominios.

Patrones tácticos

  • Entidades ricas — las entidades (Mascota, Factura, Cita) encapsulan reglas de negocio y solo mutan su estado mediante métodos que representan acciones del dominio, nunca por setters externos.
  • Value Objects — conceptos inmutables definidos por sus atributos (dinero, direcciones, códigos). Se validan en construcción y no tienen identidad propia.
  • Aggregate Roots — controlan la consistencia interna del agregado; son la única puerta de entrada para modificar el grupo de objetos que representan.
  • Domain Events — hechos significativos (ClienteRegistradoEvent, CitaAgendadaEvent) publicados asíncronamente para notificar a otros contextos sin acoplarlos directamente.
  • Interfaces de repositorio en el dominio — el dominio declara los contratos (IClienteRepository, etc.); la implementación técnica vive en Infraestructura.

Clean Architecture

  • Dominio aislado — la capa de Domain no tiene referencias a frameworks de persistencia, bases de datos ni librerías HTTP.
  • Casos de uso atómicos (SRP) — cada acción del sistema tiene su propia clase UseCase (RegistrarClienteUseCase, etc.), facilitando el testeo unitario y el mantenimiento.
  • Inversión de dependencias (DIP) — las dependencias externas se acoplan a abstracciones del dominio inyectadas por el contenedor IoC nativo de ASP.NET Core.
  • DTOs y mapeadores — las entidades internas nunca se exponen directamente en la API; se usan objetos de transferencia específicos para proteger el modelo de dominio.