Soy nuevo en microservicios y, según tengo entendido, DDD dice que los microservicios se construirán en torno a dominios comerciales. Esto significa que los buenos microservicios serían como AppointmentScheduler y SendNotification en el contexto de un sistema de reserva de reuniones.
En este ejemplo, ambos microservicios requerirán acceso a los datos del usuario para cumplir con sus funciones comerciales, y estoy luchando con la mejor manera de proporcionarlos.
Para mí, un Usuario parece un objeto que debería existir como una entidad dentro de un microservicio , pero necesitaría existir en la mayoría de los microservicios ya que los datos del usuario se requieren en casi todas partes. Esto también introduce mucha duplicación.
La otra opción es tener un microservicio de usuario que proporcione operaciones CRUD en la base de datos del usuario. Esto puede ser utilizado por otros microservicios para acceder a los datos del usuario, pero el problema que tengo con él es que une estrechamente los servicios hasta el punto en que terminamos con un monolito distribuido, que es ligeramente mejor que un monolito en sí mismo.
¿Mi razonamiento parece válido? ¿Cómo están lidiando los demás con el problema?
fuente
Respuestas:
Si realmente necesita el mismo objeto / modelo / registro de usuario en la mayoría de sus microservicios, es probable que no necesite microservicios por separado O deberían ser independientes de objetos en lo que respecta a su conocimiento. Por lo tanto, cada microservicio gestiona un subtipo de un modelo de Usuario con los datos necesarios para su funcionalidad, con una clave que se utiliza para distinguir a ese Usuario. En un mundo ideal, de esa manera puede realizar las mutaciones necesarias y propagar los cambios en todo el sistema a través de un agente de eventos de algún tipo (suponiendo que tenga una arquitectura controlada por eventos), de lo contrario, cada servicio debería ser consciente de algunos (o todos) otros servicios y lo que están destinados a hacer y qué tipos de objetos esperan recibir.
Tenga en cuenta que en un verdadero entorno de microservicios, se espera que cada microservicio tenga su propio almacén de datos, que está aislado del resto del sistema, respaldando mi declaración inicial de que debe deshacerse completamente del concepto de una entidad de usuario .
Por ejemplo, un microservicio SendNotification solo recibiría un objeto con un identificador de websocket (que se pasa a través de los servicios, eventualmente llegando a este) y los datos que se supone que deben devolverse al usuario, y tal vez simplemente verifique que los campos necesarios están allí y envían la notificación al canal apropiado mediante el identificador WS. No tiene que saber qué tipo de objetos maneja en absoluto.
fuente