Conception d’une plateforme de distribution logicielle

Contexte du projet

Ce projet est une plateforme de distribution logicielle inspirée du modèle de Steam, actuellement en cours de développement. Même si la 1ère version visible restera volontairement simple, l’architecture a été conçue avec une vision long terme l’objectif étant d’éviter de construire une V1 contraignante à faire évoluer.

Rôle & organisation

Mon rôle au sein de ce projet ne se limite pas au développement. J’interviens à la fois sur les aspects techniques et organisationnels du projet tels que l’analyse du besoin, le découpage des versions, la priorisation de tâches, la documentation, la modélisation des données et le maquettage de la V1.

Je suis en charge du cadrage global du projet, sans être à l’origine du produit.

Les orientations fonctionnelles sont définies en amont, et mon rôle consiste à les structurer, les traduire en solutions techniques cohérentes et assurer une base solide pour les évolutions futures.

Le projet étant amené à évoluer par étapes, j’ai mis en place une organisation via Trello pour garder une vision claire de l’avancement, des décisions prises et des prochaines priorités, avec une structuration par versions et par phases de travail.

Analyse & découpage du projet

Une grosse partie du travail initial a porté sur la compréhension du modèle produit. L’objectif était de construire un modèle de données plus avancé que la première version réellement déployée.

La V1 publique se concentrera uniquement sur la consultation de produits, mais le back-end anticipe déjà plusieurs besoins futurs tels que la gestion des produits, relations entre produits, fichiers, formats, systèmes supportés, médias, mises à jour, contenus associés et droits d’accès internes.

On distingue deux niveaux d’évolution : la version visible côté utilisateur, volontairement restreinte au départ, et la version technique du modèle de données, plus complète, pensée pour supporter les futures évolutions sans impacter toute l’architecture.

Modélisation des données

Une première phase a consisté à définir un dictionnaire de données (identification, typage et documentation des champs) ainsi qu’un diagramme relationnel.

La base PostgreSQL sert de source de vérité et les entités TypeORM viennent la refléter de manière explicite. Chaque relation, contrainte, enum, clé composite ou exception est documentée pour rester compréhensible dans le temps.

Stratégie DTO

J’ai mis en place une stratégie DTO distincte selon les usages.

Les DTO de lecture sont volontairement larges au départ pour couvrir rapidement le modèle. À l’inverse, les DTO de création et de mise à jour sont beaucoup plus stricts et ne sont créés que lorsqu’un vrai flux applicatif existe. Ils ne recopient pas les entités, mais représentent ce que le client est réellement autorisé à envoyer.

Certains champs sont volontairement absents lorsqu’ils sont générés par le back-end, sensibles, techniques ou déjà déduits du contexte parent.

Structuration & inventaires

Pour garder une vision claire du périmètre, j’ai créé des inventaires dédiés des DTO existants, DTO spécialisés, services disponibles, méthodes exposées et responsabilités de chaque couche. Cela évite de devoir reparcourir toute l’arborescence du projet à chaque décision et permet de maintenir une documentation utile pour de futurs contributeurs.

Services & patterns

Côté services, j’ai choisi d’avancer progressivement, des cas les plus simples vers les plus complexes.

Les premières implémentations concernent les tables référentielles en lecture seule. Ces services suivent un pattern _R__, c’est-à-dire : uniquement de la lecture, sans création, mise à jour ou suppression.

Les entités plus complexes, comme celles liées au produit, sont volontairement traitées dans un second temps. Elles impliquent des logiques plus avancées (relations multiples, cas métier spécifiques, transactions, orchestration), qui nécessitent une base déjà structurée.

Pour standardiser les comportements, j’ai défini des patterns d’opérations comme _R__, CRU_, CR_D ou CRUD. Ces patterns servent de repères pour adapter chaque entité à son besoin réel.

Approche globale

Le projet est structuré avec une séparation claire des responsabilités où chaque couche a son rôle, ce qui évite de tout mélanger et permet de garder une architecture maintenable.

Ce travail de structuration et de documentation demande plus de temps au départ, mais il permet de garder une vision claire sur le long terme, de reprendre rapidement ses repères et de faciliter l’arrivée de nouveaux collaborateurs.