Modelo de dominio compartido entre diferentes microservicios.

61

Imagine un escenario de dos microservicios diferentes. Uno para manejar la autenticación dentro del servicio, el otro se encarga de la gestión de usuarios. Ambos tienen un concepto de Usuario y hablarán sobre los Usuarios a través de llamadas entre ellos.

Sin embargo, ¿a dónde pertenecería el modelo de dominio de un "usuario"? ¿Tendrían ambos una representación diferente de lo que es un Usuario en el nivel de la base de datos? ¿Qué pasa cuando tenemos un UserDTO para usar en las llamadas a la API, ambos tendrían uno para sus respectivas API?

¿Cuál es la solución general aceptada para este tipo de problema arquitectónico?

Kristof
fuente

Respuestas:

36

En una arquitectura de microservicios, cada uno es absolutamente independiente de los demás y debe ocultar los detalles de la implementación interna.

Si comparte el modelo, está acoplando microservicios y pierde una de las mayores ventajas en las que cada equipo puede desarrollar su microservicio sin restricciones y la necesidad de saber cómo evolucionan otros microservicios. Recuerde que incluso puede usar diferentes idiomas en cada uno, esto sería difícil si comienza a acoplar microservicios.

Si están demasiado relacionados, tal vez realmente sean uno como dice @soru.

Preguntas relacionadas:

gabrielgiussi
fuente
21
No puedo estar completamente de acuerdo, si son completamente independientes, entonces tienes 2 monolitos. La idea es tener puntos finales inteligentes y tuberías tontas. En el contexto empresarial, terminas (actualmente mi pesadilla) golpeando la pared porque hay un modelo de dominio común implícito (implícito porque no lo previmos) y cada servicio está reinventando un% de la rueda. Y el ecosistema de microservicios está creciendo con un enfoque puesto al 100% en la funcionalidad y la propiedad del equipo, confundiéndolo con el modelo de dominio. Tenemos equipos creando nuevos servicios, consumiendo otros, duplicando mucho esfuerzo. Aún sin resolver.
juanmf
55
También hemos dejado de lado un requisito no funcional muy importante de la arquitectura, el rendimiento. Estos servicios que necesitan la salida de otros servicios, representan un enfoque de comunicación multinivel para cada RQ de cliente. Agregar latencia que no se puede abordar a menos que se realice una refactorización pesada y posiblemente una fusión de microservicio.
juanmf
3
Además, al no tener una comprensión común del modelo de dominio, los equipos aplicaron "transformaciones de desorden + objeto-objeto" innecesarias para adaptar las respuestas de los microservicios al modelo que adoptó el microservicio de llamadas. Sé que acoplar todos los servicios a un modelo de dominio común lib puede traer otros problemas operativos, pero no encuentro ninguna opción satisfactoria.
juanmf
3
@juanmf Sería muy valioso si pudiera publicar una pregunta sobre sus problemas. También estoy interesado en escuchar opiniones sobre este asunto ...
Milos Mrdovic
1
Trataré de sentarme y escribir algo que tenga sentido
juanmf
13

Si dos servicios están suficientemente entrelazados que sería difícil implementarlos sin compartir DTO y otros objetos modelo, es una señal fuerte de que no debería tener dos servicios.

Ciertamente, el ejemplo tiene poco sentido como dos servicios; Es difícil imaginar una especificación para la 'Administración de usuarios' tan complicada que mantendría a todo un equipo tan ocupado que no tienen tiempo para realizar la autenticación.

Si por alguna razón lo fueran, se comunicarían utilizando lo que son básicamente cadenas arbitrarias, como en OAuth 2.0 .

soru
fuente
4

Puede pensar en ellos como dos contextos limitados separados (en el lenguaje de diseño impulsado por dominio). No deben compartir ningún dato entre ellos, aparte de una ID utilizada para correlacionar el "Usuario" del contexto de autenticación con el "Usuario" del otro contexto. Cada uno puede tener su propia representación de lo que es un "Usuario", y su propio modelo de dominio, que es solo la información necesaria para desempeñar su responsabilidad comercial.

Recuerde que un modelo de dominio no intenta modelar una "cosa" del mundo real, sino qué es esa cosa en un contexto particular (como la Gestión de Identidad / Autorización, o Recursos Humanos, etc.).

pnschofield
fuente
2

Ambos tienen un concepto de Usuario y hablarán sobre los Usuarios a través de llamadas entre ellos.

También estoy de acuerdo con lo que dijo @soru. Si un servicio necesita los datos de otro servicio, entonces sus límites son incorrectos.

Una buena solución es lo que se le ocurrió a @pnschofield: tratar sus servicios como contexto limitado.

Hablando sobre el tema, en pocas palabras: los modelos de dominio compartido eliminan la autonomía del servicio, convirtiendo su sistema de microservicio en un monolito distribuido. Que aparentemente es incluso peor que un monolito.

Por lo tanto, aún queda una pregunta general sin resolver: cómo definir los límites del servicio o el contexto, para que prosperen con una alta cohesión y una bondad de acoplamiento flexible.

Se me ocurrió una solución para tratar mis contextos como una capacidad comercial. Es una responsabilidad empresarial de alto nivel, funcionalidad empresarial, que contribuye al objetivo comercial general. Puede pensar en ellos como pasos que su organización debe seguir para obtener valor comercial.

Mi secuencia típica de pasos que tomo al identificar los límites del servicio es la siguiente:

  1. Identificar capacidades empresariales de nivel superior. Por lo general, son similares entre las organizaciones del mismo dominio. Puede tener una idea de cómo se ve al verificar el modelo de cadena de valor de Porter .
  2. Dentro de cada capacidad, profundice e identifique subcapacidades.
  3. Tenga en cuenta la comunicación entre las capacidades. Mira lo que hace una organización. Por lo general, la comunicación se concentra dentro de las capacidades, notificando al resto sobre el resultado de su trabajo. Entonces, al implementar la arquitectura técnica, su servicio también debe comunicarse a través de eventos. Esto tiene múltiples consecuencias positivas. Con este enfoque, sus servicios son autónomos y coherentes. No necesitan comunicación sincrónica ni transacciones distribuidas.

Probablemente un ejemplo de esta técnica sea de su interés. No dude en decirme qué piensa, ya que este enfoque me pareció muy rentable. Claro que también puede funcionar para ti.

Zapadlo
fuente
1

El microservicio no se trata de "no compartir nada", sino de "compartir lo menos posible". En la mayoría de los casos, "Usuario" es una entidad realmente común (solo porque el Usuario se identifica mediante algún identificador compartido: ID de usuario / correo electrónico / teléfono). Tal tipo de entidades compartidas por definición. El modelo de usuario está fuera del alcance de un microservicio. Por lo tanto, debe tener un esquema global, donde se debe colocar Usuario (solo sus campos más comunes). En caso estricto es solo ID.

Evgeniy Ostapenko
fuente