Para ilustrar el problema, usamos un caso simple: hay dos agregados:Lamp ySocket. Siempre se debe aplicar la siguiente regla de negocios: Ni unLamp ni unSocket se puede conectar más de una vez al mismo tiempo. Para proporcionar un comando apropiado, concebimos unConnector-servicio con elConnect(Lamp, Socket)-método para enchufarlos.

Debido a que queremos cumplir con la regla de que una transacción debe involucrar solo un agregado, no es aconsejable establecer la asociación en ambos agregados en elConnect-transacción. Entonces necesitamos un agregado intermedio que simbolice elConnection sí mismo. Entonces elConnect-transacción solo crearía un nuevoConnection con los componentes dados. Desafortunadamente, en este punto comienzan los problemas; ¿Cómo podemos asegurar la consistencia del estado de conexión? Puede suceder que muchos usuarios simultáneos quieran conectar los mismos componentes exactamente al mismo tiempo, por lo que nuestra "comprobación de coherencia" no rechazará la solicitud. NuevoConnection-aggregates se almacenarían, porque solo bloqueamos a nivel agregado. El sistema sería inconsistente sin siquiera saberlo.

Pero, ¿cómo debemos establecer el límite de nuestros agregados para garantizar nuestra regla comercial? Podríamos concebir unConnections-aggregate que reúne todas las conexiones activas (comoConnection-entidad), habilitando así nuestro algoritmo de bloqueo que rechazaría correctamente duplicadosConnect-peticiones. Por otro lado, este enfoque es ineficiente y no escala, además es contra-intuitivo en términos de lenguaje de dominio.

¿Sabes lo que me estoy perdiendo?

Editar: Para resumir el problema, imagine un agregadoUser. Dado que la definición de un agregado es una unidad basada en transacciones, podemos imponer invariantes bloqueando esta unidad por transacción. Todo está bien. Pero ahora surge una regla comercial: el nombre de usuario debe ser único. Por lo tanto, debemos de alguna manera conciliar nuestros límites agregados con este nuevo requisito. Asumiendo que millones de usuarios se registren al mismo tiempo, se convierte en un problema. Intentamos asegurarnos de que este invariante no esté bloqueado, ya que varios usuarios significan múltiples agregados.

De acuerdo con el libro "Diseño impulsado por el dominio" de Eric Evans, uno debe aplicar la consistencia eventual tan pronto como múltiples agregados estén involucrados en una sola transacción. Pero, ¿es este realmente el caso aquí y tiene sentido?

Aplicar la coherencia eventual aquí implicaría registrar elUser y luego verificando el invariante con el nombre de usuario. Si dosUsers realmente establece el mismo nombre de usuario que el sistema deshacería el segundo registro y notificaría alUser. Pensar en este escenario me desconcierta porque interrumpe todo el proceso de registro. El envío del correo electrónico de confirmación, por ejemplo, tuvo que retrasarse, etc.

Creo que me estoy olvidando de algo en general, pero no sé qué. Me parece que necesito algo como invariantes enRepository-nivel.