¿cual es la estrategia correcta para crear un codigo incremental?
bareser opened this issue · 2 comments
Hola, estoy desarrollando una serie de bounded context o clases con son: Product , ProductCategory , ProductFamily, es decir, un producto y su jeraraquía.
Necesito que además del uuid estas clases tengan un campo código que tenga la siguiente lógica:
ProductCategory: el primer registro sea 1000 el siguiente 1001, el siguiente 1002, etc
FamilyCategory: el primero registro sea 1000 el siguiente 1001, el siguiente 1002, etc
Product: la concatenación del ProductCategory+FamilyCategory+Product ejemplo: 1001-1001-000001
Mi duda es, por ejemplo, para el caso de ProductCategory, ¿donde es correcto crear la lógica para generar el código que corresponda al crear un nuevo ProductCategory ?
Tengo 2 opciones pero no sé si son correctas, para seguir el modelo DDD CQRS de esta plantilla y no violar los principios DDD CQRS:
-
Tengo un repository mysql en el que consulto el codigo "Max(code)" que hay almacenado en mysql
En el CommandHandle invoco a este repositorio y que me proporcione el codigo que corresponda y se lo paso así en el handle hacía el ProductCategory (dominio).
En este caso mi dominio no sabe nada de calcular este codigo, simplemente le llega y ya está. -
Hago toda esta lógica en el dominio, en en mi clase ProductCategory, hago uso del repositorio correspondiente y dentro de la funcion "create" consigo el codigo correspondiente.
De esta forma mis commands y mis handle no saben nada y mi dominio se encargaría de buscar todo.
¿Me pueden ayudar? Gracias.
La opción 2 aunque simplemente supone romper la responsabilidad de un repositorio (persistir y recoger información) y darle poderes de composición.
Sin tener mucho más contexto que el expuesto yo tendría un CodeFactoryInterface en dominio y su implementation en Infra. Este usaría INCR de redis o una tabla de Codes en mysql y por supuesto usaría lock tables para no liarla con la concurrencia.
Gracias, seguiré esa línea que en mi opinión creo que es la que sigue con la teoría de la arquitectura de esta plantilla.
La idea es tener una interface, en mi clase de dominio ProductCategory, que me dé el último codigo (o máximo) y en mi logica de negocio comprobaré si es null (estaremos en 1º registro de todos) con lo cual asignaría un 1000 y en caso contrarios code+1