¿Pero qué cojones es el modelo?

Chavalada, en mi poco tiempo en esto del desarrollo os digo que pocas cosas tengo tan seguras como lo que voy a decir a continuación: el modelo no es una jodida base de datos. Una base de datos NUNCA puede ser el modelo. De hecho, decir que el modelo es una base de datos es la misma aberración que decir que un modelo es un XML, un CSV o un archivo de texto.

El modelo es pura abstracción: no hay sistema operativo, ni frameworks, ni tablas. Insisto, ¡NO HAY TABLAS!

El modelo no son los trazos que representan el número 8, sino el número como abstracción. Es algo conceptual, puro, casi etéreo y sagrado. Decir que el modelo es la BBDD es casi un insulto. ¿Tan poco valoras tu dominio para casarlo con una representación determinada, que para colmo siempre se acaba traduciendo en palabras como “tabla”, “fila”, “columna? La entidad, el concepto… lo es todo.

Ensuciarlo con terminología de bases de datos solamente denota una falta de visión del dominio. Hay gente se empeña en ver claves ajenas, inner joins, consultas de consultas, procedimientos almacenados… Todo eso está muy bien, pero no dejan de ser trazos, un bitmap, un dibujo del número 8, no el número en sí mismo.

Habrá gente que me diga que me pongo filosófico respecto al tema (como es costumbre en mí), que no hace falta ser tan extremista con el tema y que en el fondo nos basta con pensar que la base de datos es un modelo válido. Es cierto que normalmente una base de datos puede representar con cierta fidelidad un dominio, pero no deja de ser eso: una representación.

La programación como arte que evoluciona tiende a ser cada vez más cercana al dominio. Hay muchos patrones arquitecturales que hablan directamente de “Modelo”. MVC, MVP, MVVM… es un hecho que trabajar cerca del modelo tiene unas ventajas (obvias). De ahí mi gusto por DDD. Por el contrario, trabajar sin un modelo suficientemente refinado y lejos del ruido de las tecnologías subyacentes tiene innumerables inconvenientes.

Conozco casos en los que se ha usado un XML como modelo. ¿Os podéis imaginar lo que pasó? Mierda, mierda y más mierda. Aplicaciones imposibles de modificar, acoplamiento infinito.

Tenemos que alejarnos de eso. Una BBDD tanto si es relacional como si no, es tan solo una manera de almacenar datos con cierta estructura. Otra cosa es que haya aún demasiada gente que ha estado tan apegada a SQL que no sepa ver más allá de filas, columnas y selects.

I’m starting to hate the Repository pattern

What we supposedly use the Repository pattern for?

  • For querying the model?
  • For CRUD operations?
  • To have work with entities like they were already loaded in memory?
  • To not depend on underlying technologies like ORMs?

Pure junk! All those arguments could live in the 2000s, but they are now absolutely outdated!!

I’m done with that pattern. It doesn’t offer a **** and instead of this, it just adds complexity and a bunch of classes and interfaces that restrict your queries to a poor set. It’s OK that you can write your own methods in a custom repository, but as you do, it loses its maintainability and it can really get riddled with tenths of methods for each kind of query you want to get (and this really gets worse when you have to retrieve lots of different DTOs).

So, forget about this pattern if you’re getting data access seriously and start researching on new ways to do MORE, not the same or less.

Use an ORM! and don’t wrap it! if you do, you’re losing your precious time. Do you think that a change in the Database will not affect you if you wrap, and wrap, and wrap it again? HA! In the best of cases you will end up having to design 200 DTOs and 1000 different methods to access the database in a “decoupled” way.

So if you try to make an onion, good luck!

DDD principles in a visual designer? Part 1

Yeah, boys, I’m crazy to think about applying DDD to an application like this, but I feel that being so purist has some great consequences to my designs, taking some benefits from this way of thinking  about development.

Domain-driven design, taking as it sounds, is to put the focus on the domain. Think about the domain and about how the model HAS TO BE. Let the rest flow as you need it. Everything should be subsidiary (although it will be important, too).   Take the true essence of the domain of it and make a model.

That model can be simple or incredibly complex, but you have a model and you can talk about it using concepts and relations that flow naturally from it. The model is self-contained and has to describe any substantial change of the domain it represents. You can talk about it as a whole!

That’s really cool.

But there are situations where the model is a bit strange. What if the model is not a common entity like a Person, a Bank Account or a Product? What if you have to deal with entities that are commonly attached to the UI, the layout or part of a document, like a Paragraph, a Rectangle, a Field…?