L’architecture agile – Partie 2 : Séparation de la couche de base de données
Dans notre dernier Post sur l’Architecture basée sur les cas d’utilisation, nous nous sommes intéressés a la séparation du mécanisme de livraison et nous avons montré comment utiliser le principe d’inversion de contrôle afin de découpler le MVC de notre architecture applicative afin de le considérer comme un plugin. Par la suite, nous avons expliqué plus en détail l’apport des dépendances en orienté objet. Nous avons aussi parlé des limites de l’architecture, et des considérations à prendre afin de bien compartimenter l’architecture. Dans ce Post, il nous est rendu alors facile de répondre a la question que nous avons posé concernant persistence dans le modèle d’architecture basée sur les cas d’utilisation.
Nous avons vu les trois niveaux d’objets : Entités, Intéracteurs et Boundaries, et nous nous sommes questionnés a la fin du Post si nous devions persister ces entités des le depart? devons nous définir et utiliser une base de données? Apres tout, c’est tres facile avec les ORMs à la Doctrine!
Le fait que cela soit facilement faisable n’est pas un argument valide. Rappelons un point très important, la façon dont les données sont structurés dans la base de données n’est pas du tout pareille a celle qui est organisée dans nos intéracteurs ni dans nos entités.
Et comme nous avons vu dans le post sur les limites entre les composants, nous voulons avoir une couche qui sépare notre base de données de nos entités et intéracteurs, en utilisant un ensemble d’interfaces définis du coté de l’application, implémentées par la couche base de données, avec toutes les dépendances qui pointent à l’extérieur de la BD et vers la couche applicative.
Généralement, c’est l’intéracteur qui sait quand ouvrir, commiter, rollbacker une transaction. C’est l’intéracteur qui connait comment manipuler la base de données en utilisant la bonne couche. C’est l’intéracteur qui utilise les Abstractions de la base de données du coté de l’application.
Les implémentations de ces abstractions du coté de la base de données construisent des Objets de types Entité et les retournent aux intéracteurs, ces derniers peuvent alors les utiliser pour réaliser le cas d’utilisation.
Et Ainsi, nous avons une architecture qui isole le mécanisme de livraison et la couche de base de données de la couche applicative. Une architecture qui fait de ces cas d’utilisation une Abstraction principale et un principe central d’organisation.
Imaginez à quel point cette isolation va faciliter le développement piloté par les tests (TDD) sur chaque composant. Elle rend l’exécution de ces derniers très rapides et indépendants. Nul besoin d’un serveur web, nul besoin de choisir une base de données dès le départ. En lisant les tests, nous lisons l’histoire de cette application.
Mieux encore, cette architecture nous permet de deployer indépendamment chaque composant : Pas besoin de redéployer l’application suite a changement de la couche presentation.
Vous pouvez imaginer que ce type d’architecture complexifie les choses et implique beaucoup plus de travail. Dans ce cas, la suggestion de Uncle Bob est la suivante : “Allez parler à votre maman, elle va vous dire que Si vous organisez vos choses des le départ proprement, à la place de les mâchouiller tous ensemble et les jeter sur le lit, vous allez passer beaucoup de temps à la recherche de ce que vous avez besoin.”
Une architecture bien organisée nous fait avancer plus rapidement. Tout le monde sait où toutes les choses sont, c’est très facile de rester hors de la voie des autres.
