Precomputa sin miedo que no muerde.

Parece ser que, en el mundo de la gente que intenta aplicar DDD, hay mucha reticencia a la hora de hacer cálculos en diferido fuera de la operación principal (agregado raíz) que necesita los resultados de ese cálculo. Eso es un error que te empantana hasta las tetillas y te hace liarla muy parda.

Que no Neo; que no hay cuchara.

En DDD las entidades no existen. ¡BUM! Toma locura gorda; contradiciendo todos los textos existentes sobre el tema... o no ;-)

The big idea is messaging

Esta es la continuación de la entrada enterior.

Pues sí, mensajes; el concepto más importante de la P.O.O. y el más ignorado y olvidado tanto por desarrolladores como por los diseñadores de lenguajes de programación O.O. Y eso es una pena porque los mensajes aportan un cosa imprescindible: Contexto. Y ese contexto es lo que nos permite diseñar agregados que no tengan que ser elementos persistibles y que no filtren detalles de su implementación.

Los agregados no son elementos persistibles.

Si habéis leído ciertas entradas en este blog; alguna vez me habréis visto comentar que hacer que un agregado sea un elemento que se guarda en persistencia a bloque (y por ende se lee de persistencia a bloque) es un detalle de implementación que no es obligatorio y no debe afectar al diseño del agregado ni que este dependa del esquema de persistencia.

Hidratar agregado con event sourcing.

Esta entrada, al igual que las anteriores (las que van entre ésta y ésta), es generada por la conversación que tuve con unos desarrolladores de software hace no mucho.

Cuando comentábamos los pormenores de la implemntación de un pequeño test de código, uno de ellos hizo un comentario con terribles implicaciones; puesto que denota una falta de profundidad en el entendimiento y comprensión sobre agregados, eventos y event sourcing (ES).

Los eventos nunca fallan III

Épica la transparencia de la charla de ClearMeasure de Jeffrey Palermo con respecto a los "fallos" de los eventos:

Los eventos nunca fallan II

Me han puesto un ejemplo de un "fallo" de evento y creo que ya entiendo algunos de los casos por los que alguien puede llegar a creer que un evento falla. Vamos a ello.

Los eventos nunca fallan

Seguro que cuando has leído el título has pensado: "!Y un huevo que no!". Déjame explicarme un poco más para que se entienda el título de esta entrada.

Hace poco he charlado sobre arquitectura con otro desarrollador de software y me hizo un par de preguntas que no tienen sentido sobre que pasa cuando falla un evento que me dejó bastante mosqueado con respecto a si ese desarrollador tiene completamente claras las cosas o tiene algún concepto que le baila un poco y no está del todo encajado en el puzle.

La mejor FAQ de CQRS que he encontrado.

¿Para qué reinventar la rueda? Si ya está hecho y mucho mejor de lo que yo haría.

Clarified CQRS

DDD & CQRS FAQ

Querying the Domain.

En una entrada en SapiensWorks sobre DDD he tenido una interesante discusión que voy a dejar aquí para que no se pierda en un futuro.

Esto es una de las lineas del post:

CQRS: have one model (behaviour and data) handling business state changes and at least one other model handling non-domain queries

Y esto los comentarios generados:

Los Microservicios requieren macrodiseño.

Respondiendo una pregunta en StackOverflow sobre el tema; me he dado cuenta que la cosa daría para una pequeña entrada.

Microservicios es la palabreja de moda. Antes de que la mayoría de empresas medianas en vías de desarrollo hayan podido siquiera empezar a implantar decentemente SOA y ESB's en sus procesos de negocio informatizados ya salta algún geek que te dice que eso esta out; que el camino a seguir son los microservicios.