Architecture (macro) d’un service Web

(re)Passons aux choses sérieuses !

Donc la question, c’est quelle est la façon d’organiser un service web… comme un site marchand par exemple.

En particulier, comment traiter le coeur du service, c’est à dire les bases de données ?

Habituellement, on sépare le service web en « deux parties » :

  • Le front-office : c’est la partie visible par les clients du service. Pour un service e-commerce, c’est le site marchand lui-même.
  • Le back office : c’est donc tout le reste. En fait, le back office regroupe beaucoup de modules (suivant la taille des projets) : CRM, emailing, outils de tracking (business intelligence), lien vers le système logistique, …

Chaque partie à besoin de bases de données pour travailler.

Comment faire ?

  • Faire une seule base, et brancher tous les modules sur cette base centrale ?
  • Mettre une base par module, et développer des logiciels de synchronisation, pour que les données des différents modules soient cohérentes ?

En fait, il n’y a pas de réponse systématique, et il faut prendre en compte beaucoup de paramètres :

  • En règle général, il vaut mieux que le front office ai sa propre base de données, que cette base de données soit exclusive pour le front donc. L’idée, c’est que rien ne doit impacter le front office, qui est le moteur business.
  • On développe rarement les modules « à partir de rien » : on utilise un « framework » pour le front, un module type Sugar CRM pour le CRM, … Or, ces modules ont leurs propres bases de données.
  • Un autre paramètre est le nombre d’Internautes utilisant le Front. A partir d’un certain volume, on n’a plus le choix, il faut une base spécifique pour le Front.
  • Le prix bien sûr, prix des licences logicielles et prix des développements.
  • En particulier, si on a plusieurs bases de données, la synchronisation entre ces bases devient le point clé. Il faut développer des modules de synchronisation, avec des stratégies (quand doit on synchroniser, sur quels évènements). Il faut également penser aux évolutions : les bases de données sont faites pour évoluer. Il faut des modules de synchro pour gérer les versions des bases.

Dans tous les cas, il faut penser cette architecture des bases de données avec soin, c’est l’épine dorsale de tout le système.

2 commentaires

  1. Oui, c’est logique. Mais si tu as besoin d’information en temps réel qui remonte de ton front vers ton back office, comment fais tu?

    Par exemple Hervé s’enregistre en ligne puis valide son panier. Un bug surgit, il prend son phone et call le helpdesk; celui-ci devrait se plugger juste sur la BD du back???

    ++

    Silat

  2. @Silat> Très bonne question.
    Le help desk accède effectivement au back office, mais on peut compléter cet accès par une autre application, d’administration du Front.

    Tu as d’autres suggestions ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *