Les limites (boundaries) des modules dans l’architecture Logicielle
Les systèmes logiciels sont sillonnés par les limites (Boundaries), le code de part et d’autre de ces limites est bien différent. Des exemples de limites sont par exemple la limite entre le module definissant les objets du domaine et le module du mecanisme de livraison, ou encore la limite entre les vues et les modèles dans un module MVC.
Pour chacun de ces modules, un coté est abstrait et un coté est concret. Par exemple, le mécanisme de livraison est un coté concret, et le module des objets d’affaires quand à lui, est abstrait.
Nous avons vu aussi dans le dernier article sur l’architecture, que tout le code source pointe vers l’extérieur depuis le côté concret vers le côté abstrait.
Exemple : La couche de base de données
Par exemple, dans le cas de la limite entre le module de gestion de base de données et le module des objets d’affaire, la base de données est concrête, le domaine d’affaire est abstrait. Le code source doit donc pointer vers l’extérieur de la base de données vers les objets d’affaire. Ce qui revient a dire que la base de données dépend du Domaine, et que le domaine ne dépend pas de la base de données. Les experts en systèmes logiciels répétent toujours que les applications doivent être conçus a être indépendants de la base de données via une couche d’abstraction. C’est cette couche qui doit contenir votre SQL, nous ne voulons pas voir de SQL dans le module du Domaine!
Remarquez que dans le diagramme ci-dessus, que la couche d’interfaçage avec la base de données dépend de la couche de la base de données. Ceci est normal. Par contre, remarquez que la couche des objets du domaine ne dépend pas de la couche d’interfaçage avec la BD! Ceci peut sembler absurde à première vue, Mais ceci est un point clé de l’orienté objet, qui nous permet d’inverser les dépendances sans inverser la structure de contrôle. Même si la couche Application n’est pas consciente de l’existence de la couche BD, elle serait quand même capable de l’appeler.
Mais comment l’application peut ne pas connaitre la couche BD, ne pas connaitre les tables, les noms de colonnes etc?
Des structures de données et non des objets
Rappelez vous que la couche Applicative est Abstraite, alors que la couche BD est concrète. C’est une règle à ne pas oublier!
En fait, une table est une structure de données, Elle expose de la donnée et n’a pas de méthode. Ceci veut dire que c’est l’opposé d’une classe. Les bases de données sont si concrètes et n’ont aucune chance d’être polymorphiques!
Un enregistrement dans une base de données n’est pas un objet. c’est une structure de données. Une structure de données est tout le contraire d’un objet. Une structure de données expose uniquement des données et n’a pas de logique. Par contre, un objet expose des méthodes et encapsule les données.
Mais qu’en est t’il des ORM comme Hybernate, Doctrine et companie? Ces outils sont magnifiques et essentielles! Mais ce sont plutôt des Mappers entre des données et des structures de données.
Pourquoi parlons nous de tout ça? Parce qu’il est important de souligner que dans la couche d’Application, nous parlons d’objets d’affaires et non de ces structures de données.
Nous pouvons alors concevoir cette couche applicative en définissant les objets que nous voulons utiliser. Ces objets sont des vrais Objets qui exposent des méthodes et cachent les données. Au lieu de manipuler les enregistrements, nous manipulons uniquement des objets. Ceci rend l’application beaucoup plus compréhensible.
Du coté de l’application, nous voulons voir un un ensemble d’interfaces qui déclarent les méthodes d’accès aux données. nous voulons que nos objets d’affaires utilisent ces interfaces pour accéder aux données qu’ils ont besoin.
De l’autre coté de la limite, c’est-à-dire du coté de la couche de base de données, nous voulons avoir un ensemble de classes qui dérivent de ces Interfaces et Implémentent l’accès aux données en interrogeant les structures de données contenant les données qui ont récupérées depuis la base de données. Nous pouvons utiliser un ORM comme doctrine pour récupérer ces structures de données.
Ainsi, la couche de base de données dépend de l’application en utilisant ces relations d’héritage. Notez Aussi la séparation entre les objets du domaine et les structures de données. Le cote concret de la limite étant composé des structures de données.
Ceci est en fait une règle fondamentale de la conception orientée objet :
Les dépendances du code source code qui traversent la limite doivent pointer vers les abstractions à l’extérieur du cote concret. Ceci est l’un des aspects du “Principe d’inversion de contrôle”!
En mettant au clair la notion des limites dans une architecture orientée objet, et en spécifiant quelques notions de l’architecture de la couche de base de données, il nous sera maintenant facile de répondre a la question posée a la fin du dernier post, soit la séparation de la base de données dans une architecture modulaire. Ceci sera le sujet de notre prochain Post!
