Construyendo la primera, segunda y tercera fila - Territory, Flow y Ability

• El primer iniciador de cualquier caso de uso es un User, External system, o Privileged user. En ese caso es un User, y lo colocaremos en la segunda fila, la fila de Flow.
• Al colocar el User, recordamos que no se puede colocar ninguna carta sin que exista su carta de territorio, con lo que para habilitar nuestra carta User, colocamos la carta Primary adapters en la primera fila.
• Si miramos los relacionados de User, vemos que nos sugiere poner una carta Query REST controller o Command REST controller (en nuestro caso queremos hacer una Query), con lo que colocamos dicha carta en la segunda fila.
• La carta tiene un color diferente a la de User, con lo que debemos buscar una carta de territorio de su mismo color. En este caso sería la de User interface.
• El Query REST controller nos va a generar una Query según los relacionados que tiene. Con lo que la colocamos justo al lado en la segunda fila, la de Flow.
• La carta Query tiene otro color. En este caso corresponde a la carta de territorio Application layer, la cual colocaremos en la primera fila justo encima de la carta Query.
• La siguiente carta, siguiendo los relacionados, es el Query use case. Como no cambia de color, sabemos que seguimos en Application layer.
• Mirando relacionados, vemos que puede servirse de Application services y Domain services. En este caso no las usaremos. Las reservamos para más adelante en otra jugada.
• También nos percatamos que se sirve de las habilidades Persistence, Search y Notifications. Esta vez corresponde a la tercera fila, la fila Abilities. En este caso nos interesa el primero, ya que la carta Persistence representa lectura y escritura.
• Colocaremos la carta Ability - Persistence en la tercera fila que representa el territorio de Infrastructure layer, justo debajo de Application services.
• Como nos ha pasado antes, Infrastructure layer es una carta de territorio, con lo que la buscamos y la colocamos en su lugar (ya marcado por el tablero) para habilitar el territorio de la carta Persistence.
• Si miramos de continuar el flujo en la segunda fila (Flow), Query use case tiene como relacionados Aggregate root, Aggregate y Value object. Buscaremos dichas cartas y las pondremos a su lado (en este caso podemos apilarlas). Estas tres cartas, en el orden que hemos mencionado, forman nuestra jerarquía de información a nivel de Domain.
• Siguiendo la lógica de colores de las cartas, buscamos las cartas de Territory Domain layer y Domain model. En este caso son dos cartas, ya que la primera carta representa el territorio del dominio y la segunda se usa como subterritorio para mantener organizados los objetos del modelo de dominio.
• Bien. Llegados a este punto, mirando los relacionados, parece que no hay más cartas. Pues todavía nos queda una en este caso. La carta Query REST controller tiene Query use case, pero también necesita de una Response. El User hace una petición para obtener un resultado a través de Query REST controller. En este caso, lo que busca es una Response.
• Como la carta Response tiene otro color que la que tiene su compañera anterior, debemos poner otra carta de territorio. En este caso vuelve a ser User interface.

Rematando con la cuarta fila - Implementation

Como comentábamos en las reglas del juego, la primera carta en la cuarta fila es Territory - Secondary adapters, para recordarnos que sólo pueden haber cartas de dicho color.

Cada vez que desplegamos una carta Ability en la tercera fila, debemos agregar en la cuarta fila como mínimo una carta Implementation. Las cartas Implementation nos dirán la tecnología y la estrategia utilizada para implementar dicha Ability de nuestro Bounded context.

• En nuestro caso, hemos desplegado Ability - Persistence. Con lo que debemos buscar la carta Implementation que se que ajuste a dicha Ability. Dentro de las que disponemos de nuestro stack, escogemos Persistence-Postgresql. Eso nos dirá cuál va a a ser nuestra Implementation específica.
• Podemos agregar otras cartas modificadoras antes de colocar Persistence-Postgresql, como por ejemplo, Persistence strategy - ORM o Persistence strategy - SQL. Estas cartas están ahí para generar debate y son lo bastante significativas para que existan en la baraja, ya que según la estrategia que definamos, va a cambiar por completo nuestro código de implementación. Lo podemos abordar con más detalle en el futuro. Ahora escogeremos Persistence strategy - ORM, y la colocaremos entre Persistence y Persistence-Postgresql, desplazando dicha carta un poco mas abajo.

Resultado final

La “guinda” de las cartas Flow… las Exceptions

• En cualquier momento, tres cartas de tipo Flow pueden interrumpir el flujo y devolver al Query REST controller un error para mostrar al usuario. Dichas cartas son Domain exception, Application exception e Infrastructure exception. Cada una de ellas pueden pararlo todo en su territorio y hacer que el resultado del error se propague hacia las capas superiores.
• Las cartas se pondrán en un ángulo de 45 grados entre Territory y Flow, en el caso de Application exception y Domain exception, y entre Flow e Ability en el caso de Infrastructure exception.