Wallet, compte, grand livre

Un wallet n'est pas un endroit où se trouve l'argent. C'est une politique appliquée à un ou plusieurs comptes. L'argent, au sens qui intéresse le régulateur, est dans le dispositif de cantonnement, et la créance correspondante est enregistrée dans le grand livre.

Ce n'est pas de la pédanterie. Dès qu'un responsable produit demande un wallet qui peut passer en négatif, ou partagé entre deux utilisateurs, ou portant deux devises, la distinction décide si la réponse est un changement de configuration ou une réécriture.

Demandez où vit une règle. Si la règle est « ce mouvement est arithmétiquement valide et conserve la valeur », elle appartient au grand livre. Si la règle est « ce compte ne peut pas passer sous zéro », elle appartient à la définition du compte. Si la règle est « un utilisateur de moins de seize ans ne peut pas recevoir de virement hors de son groupe familial », elle appartient au wallet.

Quand les règles migrent vers le bas, le grand livre se remplit de logique produit et devient impossible à raisonner. Quand elles migrent vers le haut, la même règle est implémentée trois fois dans trois parcours et diverge en un trimestre.

Le wallet utile le plus simple a déjà besoin de plusieurs comptes derrière lui : la position réglée, les réservations tenues contre des autorisations en attente, et souvent une position distincte pour la valeur arrivée mais pas encore libérée. Présenter un seul nombre à l'utilisateur est une décision d'affichage prise par-dessus.

Se tromper là-dessus produit le bug le plus courant des produits de paiement grand public : le solde disponible et le solde affiché divergent, et le support ne sait pas dire lequel a raison parce que les deux sont calculés à des endroits différents à partir de définitions différentes.

Définissez les quantités calculées une fois, dans la couche grand livre, avec des noms. Réglé, réservé, disponible, entrant en attente. Toutes les surfaces lisent ces noms. Personne ne les recalcule localement.

Un wallet peut être fermé. Un compte ne le peut pas, en aucun sens utile, parce que les écritures qui y sont passées sont permanentes et que son historique doit rester lisible. Un utilisateur peut être effacé au titre de la protection des données pendant que les mouvements attachés à ses comptes doivent être conservés au titre de la lutte contre le blanchiment.

Modéliser le wallet séparément est ce qui rend ces deux exigences compatibles. Le wallet est fermé et les données personnelles qui s'y rattachent sont traitées selon la politique de conservation. Les comptes et les écritures persistent, identifiés par des clés qui ne renvoient plus à une personne pour quiconque n'a pas la base légale de faire ce lien.

Les équipes qui ont fait du wallet et du compte la même ligne découvrent ce conflit au pire moment, c'est-à-dire à la première demande d'effacement.

Un compte a exactement une devise. Un wallet peut en présenter plusieurs, auquel cas il se pose au-dessus de plusieurs comptes, et toute conversion entre eux est un mouvement avec un taux, un horodatage et un écart, enregistré comme n'importe quel autre mouvement.

L'alternative, un compte portant des devises mélangées avec une conversion appliquée à la lecture, fait de chaque solde historique une fonction d'une table de taux qui change sans cesse. Les soldes cessent d'être reproductibles, et la reproductibilité était le but.

Garder les trois séparés coûte quelques tables de plus et une conversation avec l'équipe produit. Les fusionner coûte la capacité de répondre aux questions sur le passé, c'est-à-dire la capacité pour laquelle le système existe.

Cette bataille de vocabulaire vaut d'être menée une fois, tôt, et par écrit.