# Les Domains
Un Domain (src/Entity/Domain.php) est une entité permettant d'avoir des informations sur le site final sur lequel sont présentées les données de l'API.
Le but principal de ce mécanisme est de pouvoir présenter des données différentes aux différents clients (au sens OAuth, src/Entity/Client.php).
En effet, un des objectifs de l'API Jindexe est de pouvoir générer des mutants Airlocal (pour mieux comprendre, se référer aux specs fonctionnelles Airlocal (opens new window)).
Ces mutants se basent tous sur Jindexe, mais disposent de données différentes :
- Un établissement inscrit sur un mutant n'apparaîtra pas forcément sur un autre mutant ;
- Les villes présentées sur un mutant n'apparaîtront pas forcément sur un autre mutant ;
- Les catégories présentées sur un mutant peuvent différer des catégories d'un autre mutant ;
- Les offres (tarifs premium pour les commerçants) présentées sur unmutant peuvent différer des offres d'un autre mutant ;
- ...
Afin de gérer ces différences, on a recours au système des Domains : chaque client OAuth est lié à un Domain, et donc chaque appel via une clef API correspondant à un client OAuth, on peut lier chaque appel à un Domain appelant.
TIP
À la création d'un nouveau mutant, il faut a minima lui générer un Domain et un client OAuth avec une clef API unique.
Un utilitaire permettant de tester la configuration d'un Domain est accessible via bin/console admin:domain:check (src/Command/Admin/DomainCheckCommand.php).
# Domaines liés
Les établissements apparaissant sur un Domain donné sont de deux types :
- Les établissements directement inscrits sur ce
Domain(cf.Professional::$domain) ; - Les établissements inscrits sur les domaines liés : un
Domainpeut avoir des$associatedDomains, c'est à dire desDomaindont il va "drainer" les établissements et publications. Cela permet par exemple de créer un mutant Airlocal Paris, un second mutant Airlocal Ile-de-France, et de déclarer Airlocal Paris comme "domaine lié" à Airlocal Ile-de-France (dans ce sens là uniquement) : les professionels inscrits sur Airlocal Paris verront leurs publications et établissement référencés dans Airlocal Ile-de-France (l'inverse n'étant pas vrai).
La fonctionnalité est intégrée au Système de filtres.
# Sérialization des catégories
Du côté des catégories (src/Entity/Category.php, src/Entity/JobOfferCategory.php, ...), le système est un peu plus complexe.
Les catégories Jindexe forment un arbre de catégories : par exemple :
Restaurant
/ \
Français Italien
/ / \
Aveyronnais Pizza Pâtes
L'arbre des catégories Jindexe représente la totalité des catégories et de leurs embranchements.
Chaque Domain peut extraire de cet arbre un sous-ensemble de catégories qu'il souhaite voir figurer sur son mutant : par exemple, Airlocal Martinique peut choisir :
Restaurant
/ \
Français Italien
/
Pizza
La conséquence d'un tel arbre de catégories est que lorsqu'un établissement s'inscrira sur Airlocal Martinique, ou qu'un utilisateur cherchera à filtrer par catégories les établissements d'Airlocal Martinique, il ne verra que les catégories sélectionnées par le mutant.
De fait, un établissement s'inscrivant sur Airlocal Martinique s'associera à des catégories Jindexe, elles-mêmes disponibles sur le mutant sur lequel il s'inscrit.
# Impact sur les Domaines liés
Cependant, Airlocal Martinique pourrait être lié à un Domain affichant la catégorie Restaurant->Italien->Pâtes, non disponible sur Airlocal Martinique.
Que se passe-t-il alors lorsqu'on liste les établissements, et qu'apparaît un établissement avec cette catégorie ?
Pour palier à ce problème, nous surchargeons la sérialization des catégories en fonction du Domain appelant.
Les catégories visibles sur un établissement dépendent de la clef API, et donc du Domain, cherchant à lister cet établissement.
TIP
Dans notre exemple, un établissement ayant sélectionné la catégorie Jindexe Restaurant->Italien->Pâtes sera visible comme Restaurant->Italien sur Airlocal Martinique.
De la même manière, un restaurant Aveyronnais sera vu comme restaurant Français sur ce mutant.
TIP
La logique appliquée à cette sérialization peut être consultée dans les différents Serializers de catégories (src/Serializer). La logique commune se trouve dans Traits/CategorySerializerTrait.php.
# Offres en fonction du mutant
En fonction du mutant, des offres différentes doivent être proposées aux établissements.
De plus, des comptes Stripe différents doivent pouvoir recueillir les paiements des différents mutants.
L'idée a donc été de déléguer intégralement la gestion des offres à Stripe. Stripe a un système de produits, de souscription à ces produits, de gestion des clients et des cartes, etc.
Au niveau du Domain, on configure donc un compte Stripe (src/Entity/StripeConfig.php) lié à ce Domain (Domain::$stripeConfig).