Aller au contenu principal

Services

Les services de Musiqud.Core, un par domaine, nommés d'après ce qu'ils possèdent. Cette liste est aussi celle des domaines, donc des tranches verticales de Core (Catalog/, Journal/…), plus Core/Shared/ pour ce qui n'appartient à aucun. Les règles sont dans Architecture du backend. Un test d'architecture échoue sur un service de Core/Services/ absent de cette liste : ajouter un domaine est une décision, et sa ligne s'ajoute ici dans le même changement.

  • CatalogService (tranche Catalog) : le catalogue. La recherche : notre copie des œuvres utilisées, cherchée dans Postgres (trigrammes), la table de popularité (TECH-14), et le fournisseur derrière ICatalog, appelé à travers un cache d'une heure. Les trois sont classés ensemble en une liste (SearchRanking).
  • WorkService (Core/Shared/Services/) : les œuvres auxquelles toutes les tranches renvoient. Trouve une sortie ou une chanson par notre identifiant ou celui du fournisseur, lit sa fiche chez le fournisseur (cache de 24 h) et la copie dans nos tables à sa première utilisation (une écoute, plus tard un favori). Une chanson est copiée avec sa sortie associée. Dans Shared, parce que le journal, les notes et les playlists en ont tous besoin, et qu'un handler ne prend jamais le service d'une autre tranche.
  • UserService (tranche Users) : les noms d'utilisateur face à la base. Dit si un nom est pris (par son squelette, donc un sosie compte; l'ancien nom d'une personne reste libre pour elle seule), réserve un ancien nom ou celui d'un compte supprimé (US-41, US-42), propose des noms libres, et tire le nom par défaut d'une nouvelle personne (user473562). Les règles sans base (normalisation, caractères, squelette, noms réservés) sont dans le helper Usernames. Le store des sessions web d'ASP.NET (SessionTicketStore) est un adaptateur d'Infrastructure. Supprime aussi le compte du fournisseur d'identité d'une personne qui supprime le sien (US-42), derrière IIdentities.
  • CollectionService (tranche Collections) : la lecture des collections d'une personne, Favori (US-17) et À écouter (US-18). Une œuvre gardée telle que l'app la voit, une tranche d'une collection de la plus récente à la plus ancienne, filtrée par type, et l'état d'une œuvre pour les bascules de sa fiche. Les écritures restent dans les handlers; la copie des œuvres passe par WorkService.
  • JournalService (tranche Journal) : la lecture du journal. Une écoute telle que l'app la voit (avec sa sortie et sa chanson), ou une tranche du journal dans son ordre, filtrée par type, après un curseur. Les handlers d'ajout, de modification et de lecture s'en servent; les écritures restent dans leurs handlers, et la copie des œuvres passe par WorkService.
  • SocialService (tranche Social) : qui suit qui (US-21, DEC-10). Retrouve une personne inscrite par le nom d'utilisateur de l'adresse, et dit si la personne connectée a fini son inscription. Les handlers d'abonnement, d'arrêt et de réponse aux demandes s'en servent; les écritures restent dans leurs handlers. Il lit aussi le fil Abonnements (US-22), les écoutes publiques des personnes suivies, et les abonnés et abonnements d'un profil (US-48), tous deux par tranches.
  • TopService (tranche Tops) : les deux Top 5 (US-27, US-28). Lit les deux listes d'une personne avec leurs œuvres, et retrouve celle dont un lecteur peut voir le Top 5, avec la même règle que son journal (DEC-10). L'enregistrement reste dans son handler, et la copie des œuvres passe par WorkService.
  • RotationService (tranche Rotations) : la rotation, ce qu'une personne écoute ces temps-ci (US-49). Lit la rotation d'une personne avec ses œuvres et sa date, et retrouve celle dont un lecteur peut voir la rotation, avec la règle du profil (DEC-10). L'enregistrement reste dans son handler, et la copie des œuvres passe par WorkService.

Tranches sans service :

  • Selections : la sélection communautaire de Pour toi (US-24). Un seul handler, ListSelectionsQuery, lit les sections publiées par ISelectionsData; elles se composent en SQL pour l'instant.
  • Moderation : les signalements (US-35). Trois handlers, ReportContentCommand, ListReportsQuery et ResolveReportCommand, sur IModerationData; rien à partager entre eux pour l'instant. La règle de qui voit quoi vient du helper Audiences.
  • Health : l'état de l'API (GetHealthQuery, derrière /v1/health et /bff/health). Son handler lit la base par IHealthData, sans logique à partager.