Curso de RDDD (Responsibility Driven Design) para empresas

Entender RDDD como un enfoque que diseña software a partir de responsabilidades y colaboraciones.

Diferenciar responsabilidad de método, tarea, requisito, historia de usuario, endpoint o tabla.

Reconocer que una responsabilidad expresa qué sabe o qué hace un elemento del sistema.

Separar responsabilidades de conocimiento, comportamiento, coordinación, decisión y comunicación.

Analizar por qué el reparto de responsabilidades condiciona mantenibilidad, testabilidad y evolución.

Evitar diseños donde una clase “gestora” centraliza casi toda la lógica.

Comprender que RDDD no obliga a crear más clases, sino a crear mejores límites.

Relacionar responsabilidad con cohesión, acoplamiento, encapsulación y autonomía.

Identificar síntomas de mal reparto: duplicación, métodos largos, dependencias circulares, tests frágiles y cambios en cascada.

Crear una definición práctica de RDDD aplicable al desarrollo empresarial moderno.

Diferenciar el rol que cumple un objeto o componente de su implementación concreta.

Identificar roles como informador, coordinador, trabajador, validador, proveedor de servicio, transformador o integrador.

Analizar colaboraciones entre roles antes de decidir nombres definitivos de clases.

Evitar que un único objeto asuma demasiados roles incompatibles.

Diseñar colaboradores que se necesiten por comportamiento y no por comodidad técnica.

Revisar qué información necesita cada colaborador para cumplir su responsabilidad.

Definir contratos mínimos entre colaboradores para no exponer detalles internos.

Detectar colaboradores que deberían ser interfaces, puertos, políticas, estrategias o servicios de dominio.

Usar roles para explicar diseño a negocio, QA y otros desarrolladores.

Construir un vocabulario común de responsabilidades y roles dentro del equipo.

Utilizar tarjetas CRC para representar clase, responsabilidades y colaboradores de forma sencilla.

Crear tarjetas sin obsesionarse inicialmente por herencia, frameworks, base de datos o nombres definitivos.

Explorar escenarios de uso moviendo responsabilidades entre tarjetas.

Detectar clases candidatas que no tienen responsabilidades claras.

Revisar colaboradores excesivos como señal de acoplamiento.

Simular conversaciones entre objetos para validar si el reparto funciona.

Usar CRC en sesiones rápidas de diseño antes de implementar features complejas.

Adaptar CRC a equipos remotos usando Miro, FigJam, tarjetas digitales o Markdown.

Convertir tarjetas seleccionadas en clases, componentes, servicios o módulos reales.

Mantener CRC como herramienta de pensamiento, no como documentación pesada obligatoria.

Leer una historia de usuario, caso de uso o requisito funcional buscando verbos de comportamiento.

Extraer reglas, decisiones, cálculos, validaciones, restricciones y efectos secundarios.

Separar responsabilidad del usuario, del sistema, del dominio, de la interfaz y de infraestructura.

Transformar requisitos ambiguos en responsabilidades verificables.

Detectar responsabilidades ocultas en frases como “el sistema deberá gestionar”, “validar”, “calcular” o “notificar”.

Identificar excepciones y casos límite como responsabilidades de decisión.

Conectar criterios de aceptación con responsabilidades concretas.

Evitar que los requisitos se traduzcan directamente en un único servicio procedural.

Crear una matriz requisito-responsabilidad-colaborador para funcionalidades críticas.

Validar con negocio que las responsabilidades propuestas representan correctamente el comportamiento esperado.

Entender cohesión como alineación entre responsabilidades relacionadas.

Identificar clases, módulos o servicios con responsabilidades demasiado dispersas.

Agrupar comportamientos que comparten datos, reglas, invariantes o motivos de cambio.

Separar responsabilidades que cambian por razones distintas.

Revisar ejemplos de baja cohesión: utilidades gigantes, managers genéricos, services con métodos inconexos y componentes multifunción.

Aplicar criterios de cohesión funcional, conceptual, temporal y de dominio.

Diseñar objetos que puedan explicarse con una frase clara.

Usar cohesión para decidir si dividir una clase o fusionar elementos demasiado fragmentados.

Evaluar cohesión en casos de uso, entidades, servicios de aplicación, módulos frontend y adaptadores.

Incorporar revisión de cohesión en code reviews y sesiones de diseño.

Reconocer tipos de acoplamiento: estructural, temporal, de datos, de framework, de infraestructura, de dominio y de despliegue.

Diseñar colaboraciones con contratos pequeños y explícitos.

Evitar que un objeto conozca detalles internos de demasiados colaboradores.

Sustituir dependencias concretas por interfaces, puertos o abstracciones cuando aportan flexibilidad real.

Detectar acoplamiento oculto mediante nombres compartidos, convenciones no documentadas o acceso directo a estructuras internas.

Analizar cambios en cascada como síntoma de mala colaboración.

Usar eventos, callbacks, policies o estrategias cuando reducen dependencia directa.

Evitar abstracciones prematuras que complican más de lo que desacoplan.

Medir acoplamiento por impacto de cambio y dificultad de prueba.

Diseñar límites que permitan sustituir detalles sin reescribir el núcleo del sistema.

Entender encapsulación como protección de invariantes y comportamiento, no solo como campos privados.

Evitar modelos que solo tienen getters y setters sin responsabilidad real.

Mover reglas de negocio hacia el objeto o servicio que mejor puede protegerlas.

Diseñar métodos que expresen intención de dominio en lugar de operaciones primitivas.

Impedir estados inválidos mediante constructores, factories, validadores o métodos de cambio controlados.

Reducir exposición de estructuras internas que otros módulos manipulan libremente.

Evitar anemias de dominio cuando toda la lógica queda en servicios externos.

Aplicar encapsulación en objetos de dominio, componentes frontend, módulos, APIs y librerías.

Revisar si un objeto puede garantizar su consistencia sin depender de llamadas externas correctas.

Crear diseños donde el código correcto sea más fácil que el incorrecto.

Relacionar Single Responsibility Principle con motivos de cambio y responsabilidad real.

Usar Open/Closed Principle para añadir comportamiento sin modificar componentes estables.

Aplicar Liskov con cuidado en jerarquías diseñadas por rol y comportamiento, no solo por similitud de datos.

Usar Interface Segregation para evitar contratos demasiado amplios entre colaboradores.

Aplicar Dependency Inversion cuando un elemento de alto nivel debe depender de políticas y no de detalles.

Detectar mal uso de SOLID como excusa para crear abstracciones innecesarias.

Revisar código existente buscando responsabilidades mezcladas detrás de violaciones SOLID.

Diseñar ejemplos donde SOLID emerge de un buen reparto de responsabilidades.

Conectar principios SOLID con testabilidad y evolución.

Crear un checklist práctico de responsabilidad y SOLID para revisiones de diseño.

Usar GRASP como conjunto de patrones para decidir dónde colocar responsabilidades.

Aplicar Information Expert para asignar comportamiento a quien posee la información necesaria.

Utilizar Creator para decidir quién debe crear objetos.

Aplicar Controller sin convertirlo en objeto todopoderoso.

Usar Low Coupling y High Cohesion como criterios constantes de diseño.

Incorporar Polymorphism para eliminar condicionales repetidos.

Aplicar Pure Fabrication cuando una responsabilidad no encaja naturalmente en el dominio.

Usar Indirection para desacoplar componentes que no deberían conocerse directamente.

Proteger variaciones con Protected Variations cuando existen cambios previsibles.

Combinar GRASP con RDDD para tomar decisiones de diseño más defendibles.

Diseñar entidades que protegen identidad, reglas, estado y comportamiento relevante.

Crear value objects que encapsulan conceptos, validaciones y operaciones pequeñas pero importantes.

Diferenciar entidad, value object, servicio de dominio, policy, specification y factory.

Evitar colocar toda la lógica de dominio en servicios de aplicación.

Identificar invariantes que deben vivir cerca de los datos que protegen.

Diseñar métodos de dominio expresivos: aprobar, cancelar, reservar, asignar, calcular, cerrar o publicar.

Mantener entidades enfocadas, evitando que se conviertan en agregados gigantes.

Relacionar responsabilidad con lenguaje ubicuo y reglas de negocio.

Usar eventos de dominio cuando una responsabilidad genera consecuencias externas.

Preparar modelos de dominio ricos pero no sobrecargados.

Diferenciar responsabilidades de un servicio de aplicación, servicio de dominio y servicio de infraestructura.

Usar servicios de aplicación para coordinar casos de uso, transacciones, permisos y llamadas externas.

Reservar servicios de dominio para operaciones que pertenecen al negocio pero no encajan en una entidad concreta.

Mantener infraestructura centrada en detalles técnicos: persistencia, correo, API externa, ficheros, mensajería o cache.

Evitar servicios de aplicación con lógica de negocio excesiva.

Detectar servicios de dominio falsos que solo contienen operaciones CRUD.

Diseñar interfaces entre capas con responsabilidades claras.

Reducir dependencia del dominio respecto a frameworks o bases de datos.

Revisar dónde colocar validaciones, cálculos, transformaciones y efectos secundarios.

Crear una guía interna para ubicar responsabilidades entre tipos de servicio.

Diseñar casos de uso como coordinadores de una intención concreta del sistema.

Separar orquestación de lógica de negocio profunda.

Definir entradas, salidas, colaboradores, transacción, permisos y errores del caso de uso.

Evitar casos de uso que simplemente trasladan datos de controller a repository.

Controlar flujo sin absorber responsabilidades que pertenecen al dominio.

Diseñar casos de uso testables sin levantar framework completo.

Manejar escenarios de éxito, error, validación y efectos secundarios.

Coordinar notificaciones, eventos, persistencia y llamadas externas de forma explícita.

Mantener casos de uso pequeños y alineados con una operación de negocio.

Revisar casos de uso como punto clave entre producto, arquitectura y QA.

Limitar controladores a recibir petición, validar formato básico, llamar al caso de uso y devolver respuesta.

Evitar que endpoints acumulen reglas de negocio, consultas, conversiones y decisiones.

Separar DTOs, comandos, queries y modelos de dominio.

Diseñar handlers de eventos con responsabilidad clara y efectos controlados.

Mantener validaciones de transporte separadas de reglas de negocio.

Usar mappers cuando la transformación entre capas tiene suficiente entidad.

Evitar acoplar dominio a HTTP, JSON, framework o interfaz.

Revisar controladores gigantes como señal temprana de mal diseño.

Probar endpoints y casos de uso con niveles distintos de detalle.

Crear convenciones para que cada entrada al sistema tenga responsabilidad limitada.

Definir repositories como abstracciones orientadas al dominio o al caso de uso, no como envoltorios genéricos de SQL.

Separar consultas de lectura, persistencia transaccional y acceso a sistemas externos.

Evitar repositories que exponen detalles de tablas, ORM o infraestructura al dominio.

Diseñar gateways para APIs externas, colas, ficheros, sistemas legacy o servicios corporativos.

Mantener responsabilidades de query, command y mapping bien separadas cuando el sistema lo requiere.

Identificar cuándo una consulta compleja pertenece a reporting, a un read model o a un caso de uso.

Evitar que la capa de datos decida reglas de negocio que corresponden al dominio.

Probar repositories y gateways con dobles, contratos o integración según riesgo.

Documentar responsabilidades de cada adaptador externo.

Crear límites claros entre conocimiento de negocio y detalle de persistencia.

Usar eventos para expresar que algo relevante ha ocurrido en el dominio.

Diferenciar evento de dominio, evento de integración, mensaje técnico y notificación.

Evitar llamadas directas entre módulos cuando un evento reduce acoplamiento.

Diseñar handlers con responsabilidad única y efectos secundarios explícitos.

Controlar transacciones, consistencia eventual e idempotencia.

Evitar eventos genéricos que obligan a los consumidores a conocer demasiados detalles internos.

Nombrar eventos en pasado y ligados a hechos de negocio.

Documentar productores, consumidores, payload, garantías y consecuencias.

Probar eventos y handlers como colaboraciones críticas.

Decidir cuándo un evento complica innecesariamente y una llamada directa es suficiente.

Ubicar responsabilidades en entidades, casos de uso, puertos, adaptadores y frameworks.

Diseñar el núcleo de la aplicación como espacio de reglas y decisiones estables.

Mantener infraestructura como detalle reemplazable.

Crear puertos que expresan necesidades del caso de uso, no capacidades técnicas genéricas.

Evitar que la arquitectura hexagonal se reduzca a carpetas sin diseño de responsabilidades.

Decidir cuándo un adaptador necesita lógica de traducción, validación o reintento.

Mantener dependencias apuntando hacia políticas de mayor nivel.

Aplicar RDDD para evitar casos de uso anémicos y adaptadores sobredimensionados.

Diseñar tests por capa respetando responsabilidades.

Crear una estructura de proyecto que refleje intención, no solo patrón arquitectónico.

Conectar responsabilidades con lenguaje ubicuo, bounded contexts, agregados y eventos de dominio.

Diseñar responsabilidades dentro de cada bounded context sin mezclar modelos de áreas distintas.

Evitar que un objeto asuma responsabilidades de otro contexto.

Usar context mapping para comprender colaboraciones entre sistemas o equipos.

Diseñar agregados alrededor de invariantes y responsabilidades de consistencia.

Aplicar servicios de dominio cuando la responsabilidad no pertenece a una entidad concreta.

Usar factories y specifications para responsabilidades de creación o validación compleja.

Evitar que DDD se quede en nombres de carpetas sin comportamiento de dominio.

Revisar si los modelos reflejan responsabilidad real o solo estructura de datos.

Crear diseños donde DDD y RDDD se refuercen mutuamente.

Asignar responsabilidades a servicios según capacidad de negocio, ownership de datos y motivos de cambio.

Evitar microservicios separados por tablas, capas técnicas o equipos temporales.

Diseñar colaboraciones entre servicios mediante APIs, eventos, contratos y procesos asíncronos.

Identificar responsabilidades que deben permanecer juntas para mantener consistencia.

Detectar servicios demasiado pequeños que solo añaden latencia y coordinación.

Evitar servicios enormes que concentran demasiadas capacidades.

Diseñar responsabilidades de integración, compensación, orquestación y coreografía.

Controlar duplicación de lógica entre servicios mediante ownership claro.

Documentar responsabilidad de cada microservicio en una frase verificable.

Usar RDDD para revisar límites antes de extraer o dividir servicios.

Diseñar endpoints desde capacidades y responsabilidades del sistema, no desde tablas.

Separar comandos, consultas, recursos, operaciones y procesos de negocio.

Evitar APIs CRUD genéricas cuando el dominio requiere acciones explícitas.

Nombrar operaciones que expresen intención: aprobar, cancelar, reservar, publicar, cerrar o recalcular.

Decidir qué responsabilidad tiene la API y qué responsabilidad conserva el consumidor.

Diseñar respuestas que no filtren estructura interna innecesaria.

Modelar errores como parte de la responsabilidad del contrato.

Separar validación de formato, validación de negocio y autorización.

Mantener versionado y compatibilidad como responsabilidades de producto API.

Revisar contratos API en sesiones de diseño orientadas a comportamiento.

Diseñar componentes de interfaz con una responsabilidad visual, interactiva o de composición bien definida.

Separar componentes presentacionales, contenedores, hooks, stores, servicios y adaptadores de API.

Evitar componentes que mezclan renderizado, estado global, consultas, validaciones y reglas de negocio.

Colocar lógica de formato, cálculo, permisos o navegación en el lugar adecuado.

Diseñar componentes reutilizables sin hacerlos tan genéricos que pierdan sentido.

Mantener responsabilidad de estado local frente a estado compartido.

Separar validaciones de UI de validaciones de dominio o backend.

Usar RDDD para organizar formularios, tablas, dashboards y flujos complejos.

Probar componentes según responsabilidad: render, interacción, transformación o integración.

Crear convenciones frontend que reduzcan duplicación y acoplamiento.

Diseñar pruebas según responsabilidades, no solo según clases existentes.

Probar unidades que encapsulan reglas con entradas y salidas claras.

Probar colaboraciones cuando el comportamiento emerge de varios objetos.

Usar dobles de prueba para colaboradores externos sin ocultar contratos importantes.

Evitar tests frágiles que dependen de detalles internos sin responsabilidad observable.

Diseñar tests de casos de uso para validar orquestación, errores y efectos secundarios.

Crear pruebas de contrato para APIs, eventos y gateways.

Relacionar criterios de aceptación con responsabilidades concretas.

Usar testing para descubrir responsabilidades mal asignadas.

Medir testabilidad como señal de buen o mal reparto de responsabilidades.

Identificar clases con demasiadas razones para cambiar.

Dividir métodos largos detectando responsabilidades internas mezcladas.

Extraer objetos de valor, políticas, validadores, factories, mappers o servicios cuando aportan claridad.

Mover comportamiento desde servicios procedurales hacia objetos de dominio cuando corresponde.

Reducir dependencia de frameworks dentro de la lógica de negocio.

Eliminar duplicación distribuyendo responsabilidades en un único lugar coherente.

Reemplazar condicionales repetidos por polimorfismo, estrategias o reglas explícitas.

Refactorizar sin romper comportamiento mediante pruebas de caracterización.

Priorizar refactorizaciones por impacto en cambio, defectos y comprensión.

Documentar mejoras de responsabilidad para que el equipo aprenda del proceso.

Leer código heredado buscando responsabilidades reales ocultas bajo nombres genéricos.

Localizar god classes, services gigantes, helpers excesivos, controladores con lógica y scripts duplicados.

Crear mapas de responsabilidades actuales antes de proponer cambios.

Identificar zonas peligrosas donde cambiar una responsabilidad puede romper muchas rutas.

Escribir pruebas de caracterización para capturar comportamiento antes de refactorizar.

Extraer responsabilidades pequeñas sin intentar rediseñar todo el sistema de golpe.

Crear seams para aislar dependencias externas, base de datos o frameworks.

Migrar hacia casos de uso, dominio o adaptadores de forma incremental.

Reducir acoplamiento por etapas, priorizando áreas con más cambios o defectos.

Convertir legacy en un sistema progresivamente más comprensible y testable.

Interpretar patrones como soluciones recurrentes de reparto de responsabilidades.

Usar Strategy para encapsular variaciones de comportamiento.

Aplicar Factory para centralizar responsabilidades de creación compleja.

Utilizar Observer o eventos para distribuir notificaciones sin acoplar emisores y receptores.

Emplear Adapter para aislar diferencias de infraestructura o sistemas externos.

Usar Facade para simplificar colaboración con subsistemas complejos.

Aplicar Command para representar intención, ejecución y trazabilidad de acciones.

Utilizar Specification para encapsular criterios de selección o validación.

Evitar aplicar patrones por moda si no resuelven una responsabilidad real.

Crear un catálogo de patrones explicado por responsabilidad, no por diagrama UML.

Crear diagramas simples de colaboración entre objetos, casos de uso, servicios y adaptadores.

Usar secuencias para validar quién llama a quién y quién decide qué.

Dibujar mapas de responsabilidad por módulo o bounded context.

Representar dependencias con C4, UML ligero, Mermaid, PlantUML o Miro.

Evitar diagramas exhaustivos que intentan reflejar cada método.

Documentar solo decisiones que ayudan a entender o mantener el sistema.

Usar diagramas en code review o diseño de feature cuando reducen ambigüedad.

Mantener modelos vivos dentro del repositorio o documentación técnica.

Señalar responsabilidades dudosas para discutirlas con el equipo.

Crear plantillas visuales reutilizables para sesiones de diseño.

Revisar pull requests preguntando qué responsabilidad se añade, cambia o mueve.

Detectar si una clase, función o módulo recibe una responsabilidad que no le corresponde.

Revisar nombres como pista de intención y responsabilidad.

Evaluar cohesión, acoplamiento, testabilidad y claridad de colaboración.

Identificar lógica de negocio en controladores, mappers, adaptadores o componentes UI.

Comprobar si los tests cubren la responsabilidad nueva.

Pedir diagramas ligeros cuando el cambio afecta a varias colaboraciones.

Evitar comentarios de estilo superficial cuando el problema real es diseño.

Crear checklist de revisión RDDD para el equipo.

Convertir code review en aprendizaje continuo sobre reparto de responsabilidades.

Asignar responsabilidades claras entre usuario, sistema, modelo IA, backend, reglas, auditoría y supervisión humana.

Separar generación de contenido, validación, decisión, explicación y ejecución.

Evitar que un modelo IA asuma responsabilidades críticas sin control ni trazabilidad.

Diseñar servicios que encapsulan llamadas a modelos externos sin contaminar el dominio.

Definir quién valida respuestas, quién registra evidencias y quién decide acciones finales.

Incorporar límites, políticas, filtros y fallback como responsabilidades explícitas.

Probar colaboraciones entre IA, reglas deterministas y flujos de negocio.

Diseñar auditoría y observabilidad para decisiones asistidas.

Evitar mezclar prompting, lógica de negocio y persistencia en el mismo bloque.

Crear arquitecturas de IA donde cada responsabilidad sea revisable y reemplazable.

Definir criterios corporativos para ubicar reglas, validaciones, consultas, transformaciones y efectos secundarios.

Crear guías de naming que reflejen responsabilidades reales.

Establecer plantillas de casos de uso, servicios, entidades, adaptadores, tests y eventos.

Revisar módulos con demasiadas responsabilidades como parte de deuda técnica.

Crear ownership por dominio, módulo, componente o servicio.

Definir cuándo una nueva responsabilidad requiere nueva clase, nuevo módulo, nuevo servicio o simple método.

Mantener documentación mínima de responsabilidades críticas por sistema.

Incluir diseño por responsabilidad en onboarding técnico.

Medir mejora mediante reducción de defectos, cambios más localizados y tests más simples.

Convertir RDDD en una práctica compartida, no en una preferencia individual.

Crear clases Manager, Processor, Helper o Service que concentran responsabilidades sin límite claro.

Diseñar entidades anémicas que solo almacenan datos mientras toda la lógica vive fuera.

Repartir una misma responsabilidad en múltiples capas o módulos.

Crear objetos demasiado pequeños sin comportamiento real solo para parecer “bien diseñado”.

Introducir interfaces para todo sin variación real ni necesidad de desacoplamiento.

Confundir responsabilidad con método y terminar con diseños fragmentados.

Colocar lógica de negocio en controladores, jobs, mappers, componentes UI o SQL.

Separar microservicios por comodidad técnica en lugar de responsabilidad de negocio.

Usar patrones de diseño sin entender qué responsabilidad resuelven.

Aceptar código “que funciona” aunque no tenga un reparto mantenible de responsabilidades.

Evaluar el estado actual del diseño del equipo: clases grandes, acoplamiento, pruebas difíciles, duplicación y deuda.

Elegir una funcionalidad o módulo piloto donde el reparto de responsabilidades sea problemático.

Realizar una sesión de diseño con CRC, mapas de colaboración o diagramas ligeros.

Definir reglas internas para ubicar responsabilidades frecuentes.

Aplicar RDDD en una feature nueva antes de usarlo en refactorización masiva.

Incorporar preguntas de responsabilidad en refinamiento, diseño técnico y code review.

Crear ejemplos internos de buen diseño y mal diseño.

Acompañar a desarrolladores junior con sesiones de modelado y revisión.

Medir mejora mediante menor retrabajo, PRs más claros, tests más simples y cambios más localizados.

Escalar la práctica de forma progresiva sin convertirla en burocracia arquitectónica.

Seleccionar una funcionalidad empresarial con reglas, validaciones, persistencia, interfaz, integración y efectos secundarios.

Extraer responsabilidades desde requisitos, criterios de aceptación y escenarios de uso.

Crear tarjetas CRC o modelo equivalente con responsables y colaboradores.

Diseñar casos de uso, objetos de dominio, servicios, adaptadores, repositories, eventos y contratos necesarios.

Definir qué responsabilidad vive en cada capa y justificar las decisiones.

Elaborar un diagrama de colaboración o secuencia que muestre el comportamiento principal.

Implementar o pseudodiseñar la solución respetando cohesión, bajo acoplamiento y testabilidad.

Preparar una estrategia de pruebas por responsabilidad: dominio, caso de uso, integración y contrato.

Detectar posibles antipatrones y proponer refactorizaciones preventivas.

Presentar el diseño final defendiendo reparto de responsabilidades, colaboradores, trade-offs, riesgos y evolución futura.