DDD y Microservicios – flujo de datos y estructura.
Estoy tratando de crear una plataforma de blogs simple y al mismo tiempo aprender más sobre DDD y Microservicios, así que quería preguntarte acerca de dos consejos en este contexto:
-
Una de las reglas de negocio que asumí en mi proyecto es que solo los usuarios en roles “Publicista” y “Administrador” pueden crear publicaciones, pero las publicaciones creadas por el “Publicista” deben ser aprobadas primero por el “Administrador” antes de que se hagan públicas. En mi comprensión, esto es parte de “Posts.Domain”, por lo que en el agregado “Post” (que a su vez es una entidad) encapsulé el cambio de estado de la publicación en métodos como “SetPublishedStatusBy” que toman datos de “Usuario” (solicitante) como parámetros y evalúan la regla anterior (+ crean eventos de dominio). Sin embargo, ahora tengo algunas dudas de si la información sobre el solicitante es realmente parte de “Posts.Domain”. Tal vez el solicitante debería evaluarse en un lugar diferente, como “Posts.API” u otro servicio, y luego se llamaría a “SetPublishedStatus” sin parámetros una vez que ya esté listo.
-
Mantengámonos en el contexto anterior. Además del microservicio “Posts”, también estoy desarrollando el microservicio “Users”, responsable de almacenar los usuarios y proporcionar algunas herramientas para que el “Administrador” los administre. ¿Cuál sería entonces el flujo de datos adecuado cuando un usuario desea publicar una nueva publicación? Lo imaginaría de la siguiente manera:
- El cliente envía el comando “PublishPost” con un ID de publicación a la puerta de enlace.
- La puerta de enlace autentica al usuario desde la solicitud HTTP (probablemente se realiza a través de una cookie con JWT).
- La puerta de enlace envía un comando “PublishPost” al microservicio “Posts”.
- El microservicio “Posts” llama al microservicio “Users” para obtener los datos relevantes del usuario desde la base de datos.
- El microservicio “Posts” recupera la publicación de la base de datos por su ID.
- Todas las reglas de negocio se evalúan a través de “Posts.Domain” y el estado se cambia a “Público”.
- El microservicio “Posts” actualiza la base de datos si todo va bien y notifica a la puerta de enlace que envía una respuesta HTTP “Éxito”.
davy.ai
Es importante considerar lo que pertenece al dominio y lo que no. En este caso, la regla de negocio sobre quién puede crear y publicar publicaciones pertenece al dominio de Publicaciones. La información del solicitante también podría considerarse parte del dominio, ya que afecta al estado de la entidad de Publicaciones. Es perfectamente válido tener métodos como
SetPublishedStatusByque tomen datos de usuario como parámetros y evalúen las reglas de negocio. Sin embargo, también es posible separar la evaluación de las reglas de negocio del dominio de Publicaciones y tener un servicio o API separado que se encargue de la autenticación y autorización de usuarios. En última instancia, esto depende de la complejidad y escala del proyecto.El flujo de datos propuesto parece razonable. El Gateway autentica al usuario y envía el comando
PublishPostal microservicio de Publicaciones. El microservicio de Publicaciones recupera los datos relevantes del usuario del microservicio de Usuarios y evalúa las reglas de negocio a través del dominio de Publicaciones. Si todo va bien, el microservicio de Publicaciones actualiza la base de datos y notifica al Gateway, que envía una respuesta exitosa al cliente. Este enfoque permite microservicios independientes y escalables que se comunican a través de una interfaz común (el Gateway). Es importante garantizar que la comunicación entre los microservicios sea segura y confiable, y que los datos compartidos estén consistentes y actualizados.