Modelo de dominio compartido entre diferentes microservicios.

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?

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:

• ¿Por qué es tan malo leer datos de una base de datos "propiedad" de un microservicio diferente?
• ¿Cómo maneja los conceptos compartidos en una arquitectura de microservicios?

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 .

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.).

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.

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.