Modelo de dominio compartido entre diferentes microservicios

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 los demás 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 sean realmente uno como @soru dice.

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 microservicio?

Si dos servicios están lo suficientemente entrelazados como para que sea difícil implementarlos sin compartir DTO y otros objetos modelo, es una señal 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 el equipo tan ocupado que no tienen tiempo para realizar la autenticación.

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

Usted puede pensar en ellos como dos Contextos delimitados (en lenguaje de Diseño Dirigido 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 realizar su responsabilidad comercial.

Recuerde que un modelo de dominio no intenta modelar una "cosa" del mundo real, sino que se trata de un contexto particular (como Identity / Authorization Management, Human Resources, etc.).

  

Ambos tienen un concepto de usuario y hablarán de los usuarios a través de llamadas entre sí.

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

Una buena solución es lo que propuso @pnschofield: tratar sus servicios como contexto limitado.

Hablando sobre el tema, en breve: los modelos de dominio compartido anulan la autonomía del servicio, convirtiendo su sistema de microservicio en monolito distribuido. Lo 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 del contexto, para que prosperen en alta cohesión y bondad de acoplamiento suelto.

Se me ocurrió una solución para tratar mis contextos como una capacidad empresarial. Es una funcionalidad empresarial de mayor nivel, responsabilidad empresarial, que contribuye a la meta comercial general. Puede pensar en ellos como pasos que su organización necesita 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 revisar modelo de cadena de valor de Porter .
2. Dentro de cada capacidad, profundice e identifique las 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. Por lo tanto, 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 cohesivos. No necesitan comunicación sincrónica y transacciones distribuidas.

Probablemente un ejemplo de esta técnica sería de cierto interés para usted. No dude en hacerme saber en qué piensa, ya que encuentro que este enfoque es muy rentable. Claro que también puede funcionar para ti.