Comment atteindre MVCC dans le modèle d'acteur

Question

Disons que j'ai représenté mon entité Employee en tant qu'acteur. J'ai 2 services également modélisés en tant qu'acteurs. Les deux manipulent l'état d'un acteur employé qu'il a reçu en lui envoyant des messages. Maintenant, disons que les deux services traitent le même acteur. Maintenant, il est tout à fait possible qu'un acteur employé de recevoir des messages de changement de l'état dans l'ordre suivant des deux services A et B

Employee <- |a1|a2|a3|b1|b2|b3|

C'est très bien. Mais parfois, ce ne est pas

Employee <- |a1|b1|a2|b2|a3|b3|

Peut-être que a2 dépendait de l'état modifié par a1, mais b1 changé

Par analogie avec les bases de données, nous avons des transactions afin que nous puissions travailler avec un seul instantané/version des données tout au long de la durée de vie des transactions. Dans le modèle impératif, nous verrouillerions l'ensemble de l'objet employé et mettrions à jour son état de la même façon que la base de données le ferait.

Est-il possible qu'un acteur puisse recevoir des messages groupés qui seront traités comme une série atomique de messages? Ou est-ce que ma modélisation de mes données elle-même est défectueuse?

Answer 1

Puisque je ne sais pas ce que représentent effectivement a1-a3 et b1-b3, je ne peux que supposer que je répondrai correctement à la question. Pour moi, il semble que vos messages sont trop fins. Par exemple, a1-a3 essaie peut-être de définir un seul attribut de données dans chaque message. La même chose vaut probablement pour b1-b3. Toutefois, vos messages doivent être ciblés sur les comportements de l'employé, et non sur la définition d'attributs individuels. Ainsi, comme vous le suggérez vous-même, concevez vos messages comme des comportements, où a1-a3 se réduirait en une seule requête d'opération. Ceci est souvent appelé le modèle de commande, où vous commandez/dites à un objet/acteur de faire quelque chose. Cela entraînera des limites transactionnelles correctes par message.

Notez que ci-dessus j'ai dit "objet/acteur". Vous pouvez/devez utiliser la même approche dans vos conceptions d'objets, pas seulement pour les acteurs. Pensez en termes d'interfaces révélatrices d'intentions et dites à votre modèle de domaine ce que vous voulez qu'il fasse pour vous, plutôt que de traiter les objets/acteurs de domaine comme des supports de données stupides.

C'est mon point de vue sur votre question. HTH.

Vaughn

Answer 2

Les deux manipuler l'état d'un acteur de l'employé, il a reçu en lui envoyant des messages.

Bien. Un acteur par définition ne partage pas son état ou sa manipulation avec un autre acteur. Toute manipulation d'état est transactionnelle dans les limites de un traitement de message. Un acteur représente un agrégat dans ce sens. Les messages sont généralement domaines événements/commandes et ont une portée et une partie du langage omniprésent. Le raisonnement de DDD aide beaucoup quand on pense aux acteurs.

Mes deux cents

Sergiy <> <