Ma question concerne ce qui devrait être fait en premier dans le développement logiciel : le modèle de base de données ou le modèle de domaine ? Ou ces notions sont-elles parallèles ? Merci.
Réponses
Trop de publicités?Cela dépend que vous soyez plutôt orienté base de données ou orienté objet. Chacun revendiquerait la suprématie et dirait que sa spécialité devrait être faite en premier.
Je serais en désaccord avec les deux. La première chose à faire est de bien comprendre votre problème. Le modèle et le schéma découleront de cela.
Vous ne pouvez pas vous débarrasser de l'imprédance de la correspondance objet-relation, peu importe ce que vous faites. Les objets sont basés sur des instances; SQL est basé sur des ensembles. Vous aurez toujours le problème.
Ce qui devrait venir en premier est la conception conceptuelle (décrivant le domaine du problème en termes confortables pour les parties prenantes), et le modèle est une conception logique basée sur la conception conceptuelle. Il existe un ensemble raisonnablement complet d'outils et de techniques pour dériver un modèle d'objet des exigences conceptuelles. Il existe quelques outils et techniques couramment connus pour passer du concept à la conception du schéma. (Le seul que je connais, qui est bon, est la modélisation des rôles d'objet.) Cependant, il existe de bonnes façons d'utiliser un modèle d'objet pour développer un schéma. Je préfère donc le modèle conceptuel au modèle d'objet au modèle de données.
Une autre façon de voir la question est que si vous développez une base de données, alors l'application tend à transformer les utilisateurs en agents de collecte de données au service du modèle de données, perdant ainsi la valeur de bonnes exigences basées sur des histoires d'utilisateurs et des cas d'utilisation (dont le second semble se transformer en CRUD.)
Remarque : de manière déroutante, la modélisation des rôles d'objet (ORM) n'a aucun lien avec la correspondance objet-relationnel (ORM).
La réponse dépendra grandement du type d'application que vous développez et des langages/cadres que vous utilisez. Si vous allez écrire beaucoup de logique métier dans la base de données (comme les procédures stockées, les vues, les déclencheurs) alors il est judicieux de concevoir d'abord la base de données. Si vous allez utiliser certains cadres qui cartographient le modèle de domaine à la base de données (et éventuellement la génération de schéma, comme hibernate) alors vous voudrez écrire d'abord les classes de domaine.
Cette vendetta familiale est plus ancienne que pirates contre ninjas. :)
À mon avis, et c'est simplement cela, commencer par le modèle de domaine aide à combler le fossé entre les exigences fonctionnelles et la conception technique. Le modèle d'objet représente mieux les données commerciales qu'un modèle de données ne le peut, et ils peuvent être schématisés pour une meilleure compréhension par les analystes commerciaux et les chefs de projet non techniques en début de projet.
- Réponses précédentes
- Plus de réponses