Un problema de muchos blogs, y en especial de éste, es que el contenido se va generando según le apetece al autor, o sea a mi, y eso hace que a veces la organización no sea todo lo buena que a uno le gustaría, especialmente si no eres un lector frecuente y caes por aquí de casualidad. Para intentar paliar ese problema, he decidido escribir este post para recopilar lo que he escrito sobre cómo diseñar modelos de dominio y así poder encontrar ese material más fácilmente.

Conceptos básicos

En el post sobre diseño de modelos veíamos distintos tipos de modelos y hablábamos sobre la evolución desde modelos relacionales a modelos orientados a objetos pasando por modelos anémicos. Merece la pena echarle un vistazo, aunque sólo sea por leer los distintos puntos de vista que se exponen en los comentarios.

Aunque no es un requisito indispensable, muchas veces se asocia tener un modelo de dominio con aplicar DDD como proceso. En ese sentido, deberías plantearte si puedes hacer DDD sin un experto de dominio. Nuevamente la discusión de los comentarios es más interesante que el post.

Cómo construir un modelo de dominio

Para diseñar un modelo de dominio, es necesario identificar los aggregate roots alrededor de los cuales construiremos el modelo, y buscar formas de enriquecerlo con comportamiento para huir de un modelo anémico.

En ese sentido, podemos quitar lógica de servicios para pasarla a entidades y value objects o darle más peso a nuestros value objects evitando usar tipos enumerados.

También podemos utilizar eventos de dominio para desacoplar el modelo de sistemas externos, aunque eso sí, debemos tener cuidado de cómo gestionamos las transacciones al usar eventos de dominio.

Conceptos sobre orientación a objetos

Al final, el modelo de dominio no deja de ser un diseño orientado a objetos (al menos en estos posts), por lo que los principios básicos de diseño orientado a objetos se aplican al modelo.

Por ello viene bien comprender lo que son la cohesión y el acoplamiento, cómo aplicar la Ley de Demeter, el principio de Tell, Don’t Ask (y los riesgos asociados) o qué significa realmente la inversión de dependencias. Tampoco está de más que cuando empieces a dejarte llevar por la fiebre polimórfica orientada a objetos, seas consciente de que no siempre se puede abstraer todo, y que si algo no lo puedes abstraer, mejor hazlo explícito.

Podemos conseguir un modelo más sólido si aprovechamos técnicas como el diseño por contrato, especialmente para tener claros los invariantes que debemos mantener dentro de cada clase que forma parte del modelo. Esto puede influir en el tipo de colecciones que usamos en cada momento. A veces el tema de los invariantes, precondiciones y demás se confunde con las necesidades de securizar, autorizar y validar.

Persistencia

Por supuesto he escrito mi buena cuota de posts sobre persistencia (¿por qué nos gustará tanto darle vueltas a lo mismo?).

Puedes empezar por ver las diferencias entre un ORM, un Micro-ORM y ADO.NET y ver cuándo usar cada uno. Si te quedan dudas, en este post explico por qué sigo usando un ORM, aunque sea algo que empieza a estar pasado de moda en ciertos círculos.

Cuando utilizas un modelo de dominio, el patrón de diseño por excelencia para gestionar la persistencia es el repositorio, en cualquiera de sus variantes: el repositorio genérico, el repositorio concreto, el repositorio implícito (usar directamente el ORM) o la separación de lecturas y escrituras. La tendencia actual es cada vez más no utilizar repositorios y usar directamente el ORM, pero los repositorios como abstracción también aportan un valor que puede ser interesante.

Una nota final

Es posible que me deje algún post que pudiera tener cabida en este resumen (si me avisas en los comentarios, lo añado), pero creo que esta «selección» incluye los posts que más te pueden servir para diseñar un bueno modelo de dominio.

No tengo por costumbre reescribir posts antiguos, y esta vez tampoco lo he hecho, por lo que es posible que si lees varios de los posts citados notes algunas inconsistencias o, directamente, contradicciones. Es normal. Todo evoluciona con el tiempo y la forma de ver las cosas cambia con la experiencia. Tómatelo como un consejo más: lo que hoy piensas que es la mejor opción, mañana puede dejar de parecértelo.