Este curso profundiza en los principios de diseño de software, con un enfoque central en los principios SOLID, y en su aplicación práctica para analizar, evaluar y mejorar código escrito en C#, particularmente en escenarios donde dicho código es generado o asistido por herramientas de inteligencia artificial.
En un ecosistema donde la IA genera soluciones funcionales en segundos, el riesgo de acumular deuda técnica acelerada es más alto que nunca. Este curso proporciona a los estudiantes las herramientas para dejar de ser un consumidor pasivo de código y comenzar a estructurar soluciones con criterio de arquitectura. A través de SOLID y principios de diseño limpio, el estudiante aprenderá a identificar y corregir las debilidades estructurales —como el acoplamiento rígido o la lógica dispersa— que los modelos de lenguaje suelen pasar por alto, garantizando software mantenible y escalable en C#.
A diferencia de enfoques tradicionales centrados en la memorización de definiciones o en la aplicación mecánica de buenas prácticas, este curso se orienta a leer y cuestionar código existente, identificar code smells, analizar dependencias y evaluar cómo un diseño responde ante el cambio, fomentando el criterio técnico por encima de la solución inmediata.
La inteligencia artificial se incorpora como un generador de propuestas y escenarios de análisis, produciendo código que cumple con los requisitos funcionales pero que debe ser examinado críticamente. El estudiante aprende a debatir con la IA, solicitar justificaciones, contrastar alternativas y tomar decisiones de diseño fundamentadas, evitando la aceptación automática de soluciones.
Al finalizar el curso, el estudiante contará con un marco mental sólido para evaluar la calidad del diseño de un código, detectar violaciones a principios fundamentales —incluidos los principios SOLID— y proponer mejoras razonadas, sentando una base firme para abordar arquitecturas y soluciones más complejas en etapas posteriores de su formación.
Objetivos
Al finalizar el curso, el estudiante será capaz de:
- Localizar code smells estructurales, distinguiéndolos de simples problemas de estilo o sintaxis, para priorizar esfuerzos de refactorización.
- Definir qué son los principios SOLID y comprender su origen e importancia en el diseño de software.
- Explicar cómo cada principio contribuye al desarrollo de software más modular, mantenible y flexible.
- Aplicar los principios SOLID y principios complementarios de diseño, evaluando cuándo su uso es apropiado y cuándo introduce complejidad innecesaria evitando la sobre-ingeniería.
- Reducir la dependencia acrítica de soluciones automatizadas, utilizando la IA como un proponente de escenarios y no como un dictador de arquitectura.
- Validar propuestas de código generadas por IA identificando violaciones a los principios SOLID y a otros principios de diseño limpio antes de su integración.
- Ejecutar procesos de "Refactorización Dirigida" mediante el debate técnico con la IA, solicitando justificaciones y comparando alternativas hasta alcanzar una solución óptima.
- Proponer mejoras de diseño fundamentadas, sustituyendo las preferencias personales por una justificación basada en principios de ingeniería de software.
- Argumentar decisiones técnicas con un vocabulario preciso, siendo capaz de explicar los trade-offs (compromisos) entre la pureza del diseño y la velocidad de entrega.
Audiencia
Este curso está diseñado para desarrolladores que ya escriben código funcional en C#, pero que desean evolucionar de "hacer que funcione" hacia "diseñar software mantenible y escalable".
Este curso es para ti si:
- Escribes clases, métodos y lógica en C#, pero no sabes evaluar si tu diseño es bueno.
- Usas IA (ChatGPT, Copilot) para generar código, pero no tienes criterio para validar su calidad estructural.
- Has escuchado sobre SOLID, acoplamiento o cohesión, pero no los aplicas conscientemente.
- Quieres aprender a leer, cuestionar y mejorar código con argumentos técnicos, no solo preferencias personales.
Perfiles típicos:
- Recién egresado o en formación. Tienes bases de POO, pero tus diseños siguen siendo rígidos o difíciles de modificar. Quieres entender qué hace "buen" código más allá de que compile.
- Desarrollador .NET usando IA. La IA te genera soluciones rápidas, pero intuyes que acumulas deuda técnica. Necesitas herramientas para detectar problemas estructurales antes de que sea tarde.
- Autodidacta con experiencia práctica. Resuelves problemas, pero buscas la base teórica que nunca estudiaste formalmente para eliminar la inseguridad técnica, fundamentar tus decisiones y dejar de sentir que programas “a ciegas” o a “prueba y error”.
Reconocerás que necesitas este curso si alguna vez has pensado:
- "Esta clase tiene 500 líneas... ¿cómo la organizo mejor?"
- "Cada cambio rompe algo en otro lado"
- "¿Acepto este código que generó la IA o no?"
- "En code reviews me piden 'mejor diseño', pero no sé qué significa"
Este curso NO es para ti si:
- Aún estás aprendiendo sintaxis básica de C# (variables, loops, condicionales).
- Buscas solo un tutorial de uso de herramientas de IA.
- Ya dominas SOLID y patrones de diseño (espera nuestro curso de arquitectura con IA).
Requisitos
Para seguir las prácticas y ejemplos, necesitarás un entorno basado en las últimas innovaciones de la plataforma .NET:
- Framework: .NET 10 SDK.
- IDE: Visual Studio 2026 (puede ser la versión gratuita Visual Studio Community) o Visual Studio Code con C# Dev Kit.
- IA Generativa. Acceso a al menos una herramienta de IA (ChatGPT, Claude.ai, Gemini o GitHub Copilot). Utilizaremos las versiones gratuitas para demostrar que el criterio técnico no depende de pagar una suscripción Pro.
Formato del curso
Las sesiones se llevarán a cabo en vivo a través de Microsoft Teams, brindando una experiencia interactiva y enriquecedora.
Durante las sesiones en vivo, los participantes tendrán la oportunidad de interactuar directamente con el instructor y con otros asistentes para resolver dudas y profundizar en los temas abordados.
Todas las sesiones serán grabadas y puestas a disposición para su descarga, permitiendo a los participantes repasar los contenidos a su propio ritmo o recuperar las clases en caso de no poder asistir en vivo. Adicionalmente, en el Team dedicado del curso en Microsoft Teams, los participantes podrán plantear dudas, continuar las discusiones iniciadas en clase y recibir acompañamiento durante el desarrollo del curso, incluso fuera del horario de las sesiones en vivo.
Material para el participante
Cada participante recibirá un manual de estudiante en formato PDF con los temas del curso.
Diploma
Al finalizar el entrenamiento los participantes recibirán un certificado digital de participación.
Fecha de inicio
Martes 3 de marzo de 2026
Horario
Martes y Jueves (dos sesiones por semana).
17:00 a 18:30 horas UTC-06. Tiempo del centro de México.
Duración
24 horas
Costo
El curso tiene un costo de 199 USD o 3,332.00 pesos mexicanos.
- Pagos realizados antes del 21 de febrero. Pago único de 99 USD o 1,658.00 pesos mexicanos.
- Grupo de 2 estudiantes con correo institucional. Pago único de 80 USD o 1,340.00 pesos mexicanos.
Estudiantes sin correo institucional, recien egresados o desempleados, escriban a logistica@ticapacitación.com para solicitar información sobre otros tipos de apoyo.
Registro
Realiza el pago en dólares a través de PayPal o en pesos mexicanos mediante transferencia o depósito bancario y envía tu comprobante a logistica@ticapacitacion.com para confirmar tu participación.
En el caso de pago de un grupo de 2 estudiantes con correo institucional, enviar los nombres y correos de los dos estudiantes junto con el comprobante de pago.
NOTA: Para la emisión de facturas en la república mexicana, el pago deberá ser realizado mediante transferencia o depósito bancario.
Enlace para pago en dólares americanos (USD) mediante PayPal
Datos para pago en pesos mexicanos mediante transferencia o depósito bancario
Número de cuenta: 0192095378
CLABE: 012650001920953784
Banco: BBVA-Bancomer-México
Si necesitas más información, escribe a logistica@ticapacitacion.com.
El cupo es limitado.
Lección 1
La trampa del código funcionalEn esta lección estableceremos la diferencia entre el código que simplemente cumple una función y el código que está bien diseñado. Describiremos la trampa del código funcional mostrando cómo la IA puede acelerar errores estructurales al dar respuestas que compilan pero que, a largo plazo, dificultan el mantenimiento y el crecimiento del sistema.
Analizaremos por qué el éxito funcional no es suficiente para considerar que una tarea está terminada. Aprenderemos a identificar la deuda técnica que introducen las herramientas generativas y a desarrollar el criterio necesario para evaluar la calidad estructural del código antes de integrarlo a un proyecto.
Introduciremos también el concepto de leer código como ingeniero: la capacidad de analizar no solo qué hace un fragmento de código, sino por qué está estructurado así, qué supuestos asume y cómo responderá ante el cambio.
Esta lección incluye la creación del proyecto que acompañará todo el curso: un sistema de gestión de pedidos generado con ayuda de la IA, que servirá como caso de estudio para analizar, cuestionar y mejorar a lo largo del curso.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Evaluar críticamente las propuestas de la IA, reconociendo que la prioridad de los modelos suele ser la funcionalidad inmediata sobre la escalabilidad.
- Diferenciar problemas estructurales de problemas de estilo, priorizando el análisis de diseño sobre la corrección superficial del código.
- Identificar señales de deuda técnica temprana en el código generado, proyectando el impacto de estas decisiones en el ciclo de vida del software.
- Aplicar criterios de calidad técnica — mantenibilidad, acoplamiento y cohesión — para emitir un primer juicio sobre la estructura de un fragmento de código.
- Leer código con criterio de ingeniero, identificando no solo lo que hace, sino cómo responderá ante el cambio.
Lección 2
El principio de responsabilidad única (Single Responsibility Principle)En esta lección aprenderemos a identificar uno de los problemas más comunes en el código generado por IA: clases y métodos que acumulan demasiadas responsabilidades. Analizaremos el concepto de cohesión como guía para determinar qué debe y qué no debe pertenecer a una clase, y aprenderemos a detectar las "fugas de lógica" donde la lógica de negocio se mezcla con la persistencia, la presentación o la validación.
Trabajaremos sobre el proyecto de pizzería generado en la lección anterior, auditando sus responsabilidades implícitas y debatiendo con la IA sobre cómo separar lo que hace demasiado. El objetivo no es dividir por dividir, sino desarrollar el criterio para reconocer cuándo una clase tiene más de una razón para cambiar y qué consecuencias tiene eso en el largo plazo.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Explicar qué significa que una clase tenga una única razón para cambiar y por qué eso importa en el ciclo de vida del software.
- Identificar clases "Dios" y métodos "navaja suiza" en código generado por IA, reconociendo las señales de baja cohesión.
- Detectar fugas de lógica donde responsabilidades distintas conviven en una misma clase, mezclando negocio, persistencia o presentación.
- Proponer una separación de responsabilidades fundamentada, justificando cada decisión con criterio técnico y no por preferencia personal.
- Debatir con la IA sobre las responsabilidades implícitas de una clase, solicitando justificaciones y evaluando alternativas antes de aceptar una propuesta.
Lección 3
El principio Abierto/Cerrado (Open/Closed Principle)En esta lección abordaremos uno de los síntomas más costosos del mal diseño: el código que debe modificarse cada vez que el negocio cambia. Analizaremos por qué los modelos de lenguaje tienden a generar soluciones "cerradas al cambio", con condicionales “hardcoded” que crecen con cada nuevo requisito, y aprenderemos a reconocer los puntos de variación donde el diseño debería ser extensible.
Utilizaremos el proyecto de pizzería para simular el dolor del cambio: agregaremos nuevos tipos de descuento y observaremos cómo un diseño rígido obliga a modificar código existente y funcional. A partir de ese experimento, rediseñaremos el sistema para que pueda extenderse con nuevas funcionalidades sin tocar lo que ya funciona, evaluando el balance entre extensibilidad y complejidad innecesaria.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Identificar puntos de variación en un sistema, reconociendo dónde es probable que el negocio exija cambios futuros.
- Detectar estructuras cerradas al cambio como cadenas de if/else o switch que crecen con cada nuevo caso de uso.
- Evaluar cómo un diseño responde ante el cambio, proyectando el impacto de modificar código existente frente a extenderlo.
- Rediseñar un sistema rígido para que sea extensible sin modificación, aplicando abstracciones apropiadas al nivel de complejidad del problema.
- Argumentar el trade-off entre una solución hardcoded y una extensible, eligiendo con criterio según el contexto y evitando la sobre-ingeniería.
Lección 4
El principio de sustitución de Liskov (Liskov Substitution Principle)En esta lección exploraremos uno de los principios más sutiles y frecuentemente violados del diseño orientado a objetos. Aprenderemos que no basta con que una jerarquía de clases compile correctamente: las clases derivadas deben respetar los contratos implícitos de su clase base, garantizando que cualquier sustitución sea transparente para el resto del sistema.
Analizaremos cómo la IA suele generar jerarquías que "funcionan" pero que ocultan violaciones lógicas: métodos que lanzan excepciones inesperadas, precondiciones más restrictivas o comportamientos que contradicen lo que la clase base promete. A través del proyecto de pizzería, identificaremos estas falsas abstracciones y aprenderemos a diseñar jerarquías honestas, evaluando cuándo la herencia es la solución correcta y cuándo la composición es preferible.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Explicar qué significa que una clase derivada pueda sustituir a su clase base sin alterar el comportamiento esperado del sistema.
- Detectar violaciones sutiles de sustitución en jerarquías generadas por IA, incluyendo precondiciones más estrictas, postcondiciones más débiles y comportamientos inesperados.
- Identificar el anti-patrón del NotImplementedException como señal de una jerarquía mal diseñada o una abstracción deshonesta.
- Evaluar si una relación de herencia es semánticamente válida o si encubre una falsa abstracción que debería resolverse con composición.
- Argumentar por qué una solución técnicamente válida puede ser lógicamente errónea, usando el principio de sustitución como criterio de evaluación.
Lección 5
El principio de segregación de interfaz (Interface Segregation Principle)En esta lección abordaremos uno de los vicios más frecuentes del código generado por IA: la tendencia a crear interfaces sobrecargadas que obligan a sus implementadores a depender de métodos que no necesitan ni usan. Aprenderemos a distinguir entre interfaces que agregan valor real y abstracciones que solo introducen complejidad accidental, desarrollando el criterio para saber cuándo segregar y cuándo simplificar.
Trabajaremos con el proyecto de pizzería para identificar interfaces "fat" creadas durante las refactorizaciones anteriores y evaluaremos si cada cliente realmente necesita todo lo que la interfaz le impone. El énfasis de esta lección no es solo aplicar el principio, sino también cuestionar cuándo su aplicación introduce más problemas de los que resuelve, combatiendo la tendencia dogmática de abstraer todo por defecto.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Identificar interfaces "fat" que obligan a sus implementadores a depender de métodos que no utilizan, reconociendo el costo del acoplamiento innecesario.
- Detectar la "arquitecturitis" en propuestas de la IA: la tendencia a crear una interfaz para cada clase sin necesidad real ni justificación de diseño.
- Segregar una interfaz amplia en contratos más específicos basados en las necesidades reales de cada cliente, no en la conveniencia del proveedor.
- Evaluar cuándo una interfaz agrega valor real al diseño y cuándo es solo ruido que incrementa la complejidad sin beneficio tangible.
- Aplicar el principio con pragmatismo, reconociendo los límites entre una segregación bien justificada y una sobre-ingeniería innecesaria.
Lección 6
El principio de inversión de dependencias (Dependency Inversion Principle)En esta lección abordaremos el principio que sienta las bases para todo lo que vendrá en el curso de arquitectura: la inversión de dependencias. Aprenderemos por qué el código de negocio no debe conocer los detalles de infraestructura, cómo el acoplamiento rígido a implementaciones concretas destruye la testabilidad y la flexibilidad del sistema, y cómo la inyección de dependencias resuelve este problema de forma elegante en C# moderno.
A través del proyecto de pizzería, identificaremos todas las dependencias ocultas que se han acumulado a lo largo del curso — instanciaciones directas, llamadas estáticas, dependencias del sistema — y las reemplazaremos por abstracciones inyectadas. El resultado será un sistema donde cambiar un mecanismo de persistencia o un canal de notificación no requiere tocar la lógica de negocio, y donde cada componente puede probarse de forma aislada.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Explicar por qué los módulos de alto nivel no deben depender de los detalles de implementación, y qué consecuencias tiene este acoplamiento en la mantenibilidad del sistema.
- Identificar dependencias ocultas en código generado por IA, incluyendo instanciaciones directas con new, llamadas a métodos estáticos y dependencias implícitas del entorno.
- Diseñar abstracciones genuinas que oculten los detalles de infraestructura sin simplemente renombrar la implementación concreta.
- Aplicar inyección de dependencias en C# usando el contenedor nativo de .NET, configurando la composición del sistema en un único punto de entrada.
- Evaluar la testabilidad como indicador de calidad del diseño, reconociendo que un código difícil de probar de forma aislada es una señal de acoplamiento rígido.
Lección 7
El criterio por encima de las reglasEn esta lección no aprenderemos principios nuevos de forma aislada: los integraremos todos en un marco de criterio técnico coherente. Revisaremos SOLID como un sistema de decisiones interrelacionadas, donde aplicar bien un principio puede tensionar otro, y donde el juicio del ingeniero está precisamente en navegar esas tensiones con argumentos sólidos y no con dogmatismo.
Incorporaremos principios complementarios que actúan como contrapesos: KISS, YAGNI y DRY para evitar la sobre-ingeniería que SOLID puede provocar cuando se aplica mecánicamente. Introduciremos también dos principios adicionales que amplían el criterio ya desarrollado: Separation of Concerns (SOC) y la Ley de Demeter como herramienta práctica para detectar acoplamiento oculto en el código generado por IA. Ninguno de estos se presentará como una regla adicional a memorizar, sino como una perspectiva que enriquece el juicio técnico.
Realizaremos un code review integral sobre el proyecto de pizzería en su estado final, evaluando las decisiones de diseño tomadas a lo largo del curso: cuáles fueron acertadas, cuáles introdujeron complejidad innecesaria y cuáles representan trade-offs válidos y bien argumentados. Identificaremos las tensiones reales entre principios — los momentos en que aplicar uno correctamente implica ceder en otro — y practicaremos cómo argumentar esas decisiones con vocabulario técnico preciso.
El curso cierra con una mirada hacia adelante: los principios vistos aquí son la base sobre la que el curso de arquitectura construirá soluciones más complejas. El estudiante que termina esta lección no memoriza reglas: ha desarrollado un ojo clínico para leer, cuestionar y mejorar código con criterio de ingeniero.
Objetivos
Al finalizar esta lección, el estudiante será capaz de:
- Evaluar decisiones de diseño considerando los principios SOLID en conjunto, identificando cómo una decisión en una parte del sistema afecta al resto y detectando tensiones entre principios.
- Aplicar KISS, YAGNI y DRY como contrapesos al dogmatismo, reconociendo cuándo la simplicidad es preferible a la pureza del diseño y argumentando esa elección con criterio técnico.
- Reconocer el principio Separation of Concerns, conectando su significado con las decisiones de arquitectura.
- Detectar violaciones a la Ley de Demeter en código generado por IA, identificando el acoplamiento oculto que produce el acceso encadenado a detalles internos de otros objetos.
- Ejecutar un code review estructurado sobre código real, documentando violaciones, justificando decisiones y argumentando trade-offs con vocabulario técnico preciso.
- Formular prompts de diseño que guíen a la IA hacia soluciones estructuralmente mejores desde el inicio, incorporando restricciones explícitas de diseño en la conversación.