Conception pilotée par le domaine et transactions dans l’environnement Spring

J’avais l’habitude de concevoir mon application autour d’un modèle de domaine anémique; j’avais donc de nombreux objects de référentiel, qui étaient injectés dans la couche de service volumineuse, complexe et sensible aux transactions. Ce modèle est appelé script de transaction. Ce n’est pas considéré comme une bonne pratique, car cela mène au code de procédure. Je voulais donc passer à la conception axée sur les domaines.

Après avoir lu quelques articles sur le Web, écouté le discours de Chris Richardson sur Parleys et lu les chapitres DDD des POJO en action, je pense avoir une vue d’ensemble.

Le problème est que je ne sais pas comment organiser les transactions dans mon application. Chis Richardson dans son livre dit:

Le niveau présentation traite les requêtes HTTP du navigateur de l’utilisateur en appelant le modèle de domaine directement ou indirectement via une façade, décrite dans le chapitre précédent sous la forme d’un POJO ou d’un EJB.
Quand utiliser les interfaces de méthode unique en Java
Création d’objects: Constructeurs ou méthodes d’usine statiques
Est-ce que ce Monster Builder est un bon modèle Builder / Factory pour extraire de longs constructeurs mélangés avec des seters?
problème de conception de génériques java (machine à états)
Différence entre le motif de décorateur et le modèle de délégation

Bien jusqu’à présent, mais Srini Penchikala sur l’ article d’InfoQ dit:

Certains développeurs préfèrent gérer les transactions dans les classes DAO, ce qui est une conception médiocre. Cela se traduit par un contrôle des transactions trop détaillé qui ne donne pas la flexibilité nécessaire pour gérer les cas d’utilisation où les transactions couvrent plusieurs objects de domaine. Les classes de service doivent gérer les transactions. Ainsi, même si la transaction s’étend sur plusieurs objects de domaine, la classe de service peut gérer la transaction car, dans la plupart des cas d’utilisation, la classe de service gère le stream de contrôle.

Ok, donc si je comprends bien, les classes de référentiel ne doivent pas être transactionnelles, la couche de service (qui est maintenant beaucoup plus fine) est transactionnelle (comme elle l’était dans le modèle de script Transaction). Mais que se passe-t-il si les objects du domaine sont appelés directement par la couche de présentation? Cela signifie-t-il que mon object de domaine doit avoir un comportement transactionnel? Et comment l’implémenter dans l’environnement Spring ou EJB?

Cela me semble un peu bizarre, alors je serais heureux si quelqu’un clarifiait cela. Je vous remercie.

Mon sharepoint vue personnel sur l’application de DDD avec Spring et Hibernate est, jusqu’à présent, d’avoir une couche de service transactionnelle sans état et d’accéder aux objects du domaine par ce biais. Ainsi, dans mon modèle, le modèle de domaine ne connaît pas du tout les transactions, cela est entièrement géré par les services.

Il existe un exemple d’application qui pourrait vous être utile. Il semble qu’Eric Evans ait été impliqué dans sa création.

Voir ce blog extrêmement utile . Il explique comment obtenir des DDD en douceur sans perdre les capacités de Spring et JPA. Il est centré autour de l’annotation @Configurable .

Mon opinion sur ces questions est un peu non populaire. Le modèle de données anémique n’est en réalité pas faux. Au lieu d’avoir un object avec des données + opérations, vous avez deux objects – un avec des données et un avec des opérations. Vous pouvez les voir comme un seul object – c.-à-d. Satisfaire la DDD, mais pour faciliter leur utilisation, ils sont séparés physiquement . Logiquement, ils sont les mêmes.

Oui, cela casse l’encapsulation, mais cela ne vous oblige pas à utiliser un peu de “magie” (agent aop + java) pour atteindre vos objectives.

En ce qui concerne les transactions – il y a quelque chose appelé la propagation des transactions. Spring le supporte avec @Transactional(propagation=Propagation.REQUIRED) . Voir cela, point 9.5.7 . Si vous souhaitez que vos transactions couvrent plusieurs méthodes (de plusieurs objects), vous pouvez modifier l’atsortingbut de propagation en conséquence.

Vous pouvez également utiliser @Transactional dans votre couche de service, le cas échéant, mais cela peut introduire un grand nombre de classes de service boilerplace dans les cas où vous souhaitez utiliser des opérations simples en une étape, telles que “enregistrer”.

Je pense qu’un moyen simple de commencer à utiliser DDD et Spring et à avoir de bons exemples de la façon de traiter des transactions consiste à consulter l’une des applications exemples fournies avec Spring Roo . Roo produit le code qui suit les principes DDD. Il s’appuie fortement sur AspectJ. Je soupçonne qu’il a été mis en œuvre sur la base des idées avancées (en 2006) par l’un des poids lourds de SpringSource, Ramnivas Laddad, dans cet exposé .

Malheureusement, je ne me suis pas familiarisé avec Spring, mais je vais donner des informations sur votre compréhension de DDD. En lisant votre description de la transaction, il est évident que vous n’avez pas compris DDD, en particulier Aggregate, Aggregate Root et Repository.

Dans DDD, les transactions ne peuvent pas s’étendre sur plusieurs agrégats, donc un agrégat aura toujours une transaction.