J'envisage un projet pour migrer une partie de notre SOA basé sur WCF vers un modèle de bus de service (probablement nServiceBus) et utiliser un pub-sub de base pour réaliser la séparation des requêtes de commandes .
Je ne suis pas nouveau dans SOA, ni même dans les modèles de bus de service, mais j'avoue que jusqu'à récemment, mon concept de "séparation" était limité à la mise en miroir et à la réplication de bases de données courantes. Pourtant, je suis attiré par l'idée car elle semble offrir tous les avantages d'un système finalement cohérent tout en évitant bon nombre des inconvénients évidents (notamment le manque de soutien transactionnel approprié).
J'ai beaucoup lu sur le sujet d'Udi Dahan qui est fondamentalement le gourou des architectures ESB (au moins dans le monde Microsoft), mais une chose qu'il dit me laisse vraiment perplexe:
Au fur et à mesure que nous obtenons de plus grandes entités avec plus de champs, nous avons également plus d'acteurs travaillant avec ces mêmes entités, et plus la probabilité que quelque chose touche certains attributs à un moment donné est élevée, ce qui augmente le nombre de conflits de concurrence.
[...]
Un élément central du CQRS est de repenser la conception de l'interface utilisateur pour nous permettre de saisir l'intention de nos utilisateurs de telle sorte que faire un client préféré est une unité de travail différente pour l'utilisateur que d'indiquer que le client a déménagé ou qu'il a obtenu marié. L'utilisation d'une interface utilisateur de type Excel pour les modifications de données ne capture pas l'intention, comme nous l'avons vu ci-dessus.
- Udi Dahan, CQRS clarifié
Du point de vue décrit dans la citation, il est difficile de contester cette logique. Mais cela semble aller à contre-courant en ce qui concerne les OSS. Une architecture SOA (et vraiment des services en général) est censée traiter les messages à granularité grossière afin de minimiser les conversations réseau - parmi de nombreux autres avantages.
Je me rends compte que le bavardage réseau est moins un problème lorsque vous avez des systèmes hautement distribués avec une bonne file d'attente de messages et aucun des bagages de RPC, mais il ne semble pas sage de rejeter complètement le problème. Udi semble presque dire que chaque changement d'attribut (c.-à-d. Mise à jour de champ) devrait être sa propre commande, ce qui est difficile à imaginer dans le contexte d'un utilisateur mettant potentiellement à jour des centaines ou des milliers d'entités et d'attributs combinés, comme c'est souvent le cas avec un outil traditionnel. service Web.
Une mise à jour par lots dans SQL Server peut prendre une fraction de seconde étant donné une bonne requête hautement paramétrée, un paramètre de valeur de table ou une insertion en bloc dans une table intermédiaire; le traitement de toutes ces mises à jour une à la fois est lent, lent, lent et le matériel de base de données OLTP est le plus cher de tous à évoluer / évoluer.
Existe-t-il un moyen de concilier ces préoccupations concurrentes? Est-ce que j'y pense dans le mauvais sens? Ce problème a-t-il une solution bien connue dans le monde CQS / ESB?
Sinon, comment peut-on décider quel devrait être le "bon niveau" de granularité dans une commande? Existe-t-il un «standard» que l'on peut utiliser comme point de départ - un peu comme 3NF dans les bases de données - et qui ne dévie que lorsqu'un profilage soigneux suggère un avantage de performance potentiellement significatif?
Ou est-ce peut-être une de ces choses qui, malgré plusieurs opinions fortes exprimées par divers experts, n'est vraiment qu'une question d'opinion?