Qu'est-ce que Java modèle de domaine?
J'étudie un livre Spring et ils mentionnent Java modèle de domaine.
Qu'est-ce que c'est?
Un modèle de domaine (le terme n'est pas du tout Java spécifique) est une classe qui modélise quelque chose dans le domaine problématique, par opposition à une classe qui existe pour des raisons d'implémentation technique.
Les instances de modèle de domaine doivent souvent être conservées dans une base de données, et en Java, elles sont généralement conformes à la spécification Java Beans, c'est-à-dire qu'elles ont des méthodes get et set pour représenter les propriétés individuelles et un constructeur sans paramètre. Spring et d'autres frameworks vous permettent d'accéder à ces propriétés directement dans vos JSP.
Par exemple, dans une application de boutique, certaines de vos classes de modèle de domaine seraient Product, Order, ShoppingCart et Customer.
Un modèle de domaine est un modèle conceptuel du domaine problématique. Par "modèle de domaine Java", ils signifient simplement les classes Java représentant ce modèle. Il n'y a rien de spécifique à Java dans le concept.
Voir aussi Domain Driven Design pour une approche pour concentrer votre développement sur les besoins du domaine métier.
Réponse de Michael Borgwardt "n modèle de domaine (le terme n'est pas du tout Java spécifique) est une classe" est faux. Je suis très surpris que beaucoup soient d'accord avec cette réponse .
Un modèle de domaine est l'ensemble des classes qui modélisent le comportement de la solution. C'est le minimum nécessaire pour accomplir le comportement requis. Le modèle de domaine est exempt de fonctionnalités d'interface utilisateur et de persistance (sauf si le problème tourne autour de l'interface utilisateur ou de la persistance).
J'ai vu un modèle de domaine implémenté dans une classe mais ce n'est pas la conception d'une solution orientée objet. Dans un modèle de domaine orienté objet, chaque concept a sa propre classe qui implémente le comportement requis de ce concept et contient les champs nécessaires pour maintenir l'état de la classe.
Commençons par un exemple. Vous créez une application avec sera utilisée par certaines personnes dans votre localité. Lorsque vous concevez le système, vous appelez ces personnes des utilisateurs de votre système. Vous devez également gérer une liste de rôles pour ces personnes dans le système et les informations d'authentification. Vous décidez donc de créer une entité conceptuelle dans le système. Cette entité conceptuelle est en outre mappée à un objet utilisateur dans votre solution logicielle (votre application). Désormais, lorsque vous représentez votre application, vous décrivez cet objet Utilisateur comme un modèle de domaine. L'idée de base derrière ce terme est cela seulement. Vous pouvez en savoir plus à ce sujet dans le --- lien Wikipedia .
Je sais que cela fait longtemps depuis le dernier post ici. Mais il est important que les informations sur ce concept soient claires. Un modèle de domaine est souvent un ensemble de classes qui représentent un domaine de problème particulier. Le concept n'est lié à aucun type d'implémentation technologique. Je pense qu'il est un peu trompeur de dire:
" Les instances de modèle de domaine doivent souvent être conservées dans une base de données, et en Java, elles sont généralement conformes à la spécification Java Beans, c'est-à-dire qu'elles ont get et set méthodes pour représenter des propriétés individuelles et un constructeur sans paramètre. Spring et d'autres frameworks vous permettent d'accéder à ces propriétés directement dans vos JSP "
Les modèles de domaine sont souvent le résultat d'une conception pilotée par domaine. La conception pilotée par domaine est la clé d'un modèle de domaine bon et robuste. Je suggère d'avoir lu le livre d'Eric Evans Domain Driven Design, pour vous donner une meilleure compréhension.
Les classes de modèle de domaine ont des informations qui leur sont associées, mais le comportement, à mon avis, est plus important que les données dans ce contexte. Une grosse erreur autour de la conception pilotée par domaine consiste à créer des classes de données qui représentent les données d'une entité de domaine, comme un client, et ne fournissent que des getters et setters publics pour les attributs client. Ces objets ont tendance à imiter la structure de votre base de données et, par conséquent, la logique métier réelle est plus susceptible de résider dans les services de domaine, ce qui entraîne un modèle de domaine anémique . Ce modèle est plus proche d'un Transaction Script qu'un modèle de domaine.
En termes simples, votre package de domaine est la représentation d'objet d'elememts dont vous auriez principalement mais pas nécessairement besoin pour afficher des champs d'interface utilisateur tels que nom d'utilisateur, info_client, pojos spécifiques à la solution, etc. Les classes contenues dans le package de domaine seront utilisées dans le DAO (DATA ACCESS OBECT), où le dao interrogera la base de données et mappera ces champs dans les classes du domaine et les renverra. Ou vous pouvez utiliser un framework comme hibernate et renvoyer cet objet, où l'interrogation de la base de données sera prise en charge par un framework comme hibernate.
Cette réponse est plus MVC et Java spécifique mais détaille l'une des implémentations possibles.