# Termes et conventions communs utilisés

L’équipe de l’Architecture de Référence a utilisé des termes et conventions communs tout au long de la conception et la documentation du modèle d’Architecture de Référence Mojaloop 2.0.

Veuillez utiliser cette liste pour vous familiariser avec des termes qui pourraient vous sembler inconnus ou oubliés. La liste contient également des références à des articles et documents tiers disponibles dans la section “Pour aller plus loin” de ce document.

Convention/Terme	Description
Acteurs	Participant humain ou système externe à un Cas d’Utilisation. Tous les Cas d’Utilisation sont initiés par des Acteurs.
BC	Bounded Context : Un Contexte Borné est un composant du Design-Driven Development et contient généralement un ou plusieurs sous-domaines. Les Contextes Bornés sont des entités de l’Espace Solution (Solution Space), et contiennent une solution unique applicable à un ou plusieurs sous-domaines. (Pour plus d’informations, voir : Vue d’ensemble de l’Architecture inspirée du DDD dans l’aperçu de l’Espace Solution, ou notre section Pour aller plus loin : Articles et Documents de Référence)
UC	Cas d’Utilisation: Liste d’actions ou d’étapes décrivant les interactions entre un Acteur (humain ou système externe) et un système pour atteindre un objectif particulier. Un exemple dans Mojaloop serait : “Effectuer un transfert avec confirmation du bénéficiaire”. (Pour plus d’informations, voir l’article Wikipédia “Use Case” cité dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
Sync	Communications synchrones, unidirectionnelles ou bidirectionnelles, faisant partie du processus initial. Représentées par une ligne pleine dans les schémas UC. Utilisées généralement pour les Messages devant impérativement figurer dans le workflow d’un UC pour assurer son exécution correcte. Exemple : une messagerie synchrone du BC Transferts vers le BC Gestion du Cycle de Vie des Participants pour obtenir des données Participant non présentes en cache lors d’une demande de transfert.
Async	Communications asynchrones, unidirectionnelles ou bidirectionnelles, ne faisant pas partie du processus initial. Signalées par une ligne pointillée dans les schémas UC. Utilisées principalement pour les Événements qui signalent qu’une action a eu lieu : c’est immuable et ne changera pas, comme les rapports de rappel (callback).
POST	Utilisé pour créer de nouvelles ressources. Plus précisément, pour créer des ressources subordonnées à une autre (ex. ressource “parent”). En d'autres termes (IOW), lors de la création d'une nouvelle ressource, on fait un POST sur le parent, le service l’associe au parent, lui attribue un identifiant (URI de la nouvelle ressource), etc. En cas de succès, le système renvoie un en-tête Location avec le lien de la ressource créée (HTTP 201). (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
GET	Utilisé pour lire (ou récupérer) la représentation d’une ressource. En cas de succès “normal”, GET retourne une représentation XML ou JSON et le code de réponse HTTP 200 (OK). En cas d’erreur, renvoie généralement un 404 (NOT FOUND) ou un 400 (BAD REQUEST). (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
PUT	Utilisé pour mettre à jour une ressource connue, en effectuant un PUT sur l'URI d'une ressource connue avec le corps de requête contenant la représentation nouvellement mise à jour de la ressource d'origine. Dans certains cas, PUT peut également servir à créer de nouvelles ressources, mais en raison de la complexité, ce n'est pas recommandé (il faut utiliser POST à la place). (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
200 (OK)	Code HTTP indiquant “Succès”. La requête a abouti. L’information retournée avec le code de statut dépend généralement de la méthode employée dans la requête : pour POST, la réponse décrit le résultat ; pour GET, la ressource demandée ; pour PUT, une réponse similaire à POST. (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
201 (Created)	Code HTTP indiquant “Créé” ou “traitée”. La ressource demandée a été créée, consultable via l’URI renvoyée dans la réponse. Si la ressource ne peut être créée immédiatement, le serveur retourne un 202 (Accepted). (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
202 (Accepted)	Code HTTP indiquant que la requête a été acceptée pour traitement, mais n’est pas terminée. Elle peut ou non être traitée selon l’état du système. L’opération étant asynchrone, il n’y a pas non plus de mécanisme pour renvoyer le code de statut quelle que soit l’issue de l’opération. La réponse 202 est délibérément non-engageante pour permettre à une requête d’être traitée sans exiger que l’agent reste connecté jusqu’à ce qu’elle le soit. La réponse doit donner un état du système, éventuellement un lien vers une plateforme de suivi ou une estimation du moment d’exécution. (Pour plus d’informations, voir la référence “Restful API Tutor” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
OHS	Open Host Service : Documentation des méthodes à utiliser pour intégrer des systèmes aval à une plateforme amont existante sans nécessiter de modifications. Apporte généralement le support de multiples types de clients, sans se focaliser sur aucun : c’est au système aval de comprendre la documentation publiée par l’amont. OHS et PL sont couramment associés par les plateformes amont. Actuellement utilisé dans les entités suivantes : API externe FSPIOP, API externe ISO, Notifications & Alertes BC, API externe PISP ML, API externe PISP ISO, Scheduling BC, Transfers & Transactions BC, Quoting BC, Accounts & Balances BC, Settlements BC, Gestion du Cycle de Vie du Participant, Account Lookup & Discovery BC. (Pour plus d’informations, voir la référence “Strategic Domain-Driven Design” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document)
PL	Published Language : Proche parent de l’Open Host Service et souvent utilisé conjointement. PL utilise un langage documenté, par exemple XML, pour les opérations d’entrée/sortie de base pour lesquelles il est utilisé. Aucun environnement ou bibliothèque spécifique n’est requis, tant que le langage publié est respecté. Le Published Language n’est pas exclusif aux web services : on peut par exemple déposer un fichier dans un dossier, déclenchant ainsi une opération qui le stocke à un emplacement spécifié par l'application. Actuellement utilisé dans les entités suivantes : API externe FSPIOP ; API externe ISO. (Pour plus d’informations, voir la référence “Strategic Domain-Driven Design” dans la section Pour aller plus loin : Articles et Documents de Référence de ce document))