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.
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
Arquitectura distribuida orientada a eventos (EDA). Cada microservicio tiene su propio Bounded Context y base de datos aislada (Database-per-Service).
| 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 |
| 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 |
Aplicación de consola interactiva que funciona como laboratorio de patrones GoF, modelada con DDD y Clean Architecture.
| 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 |
# 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 downUna 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 |
cd TiendaMascotas
dotnet build
dotnet runDesde 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.
| 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 |
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 enSharedKernelsin 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.
- Dominio aislado — la capa de
Domainno 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.