Afin de jouer cet atelier, assurez-vous d'avoir sur votre poste :

• Java 17
• Docker Compose

Amis du Snowcamp bonjour,
Nous te sollicitons car nous avons besoin de ton aide.
Nous avons externalisé le développement de notre site de vente en ligne de Chartreuse auprès de ceux que nous pensions être les plus à même de le faire, à savoir Le cabinet de conseil des frères Chartreux.

Après de nombreux mois sans la moindre évolution majeure, ni prise en compte des bugs, nous avons découvert que frère Bernard, notre développeur, avait plus tendance à contrôler la qualité de nos produits qu'à s'appliquer au développement de notre site.

Nous faisons donc appel à vous pour reprendre en l'état notre backend et développer les fonctionnalités manquantes pour, espérons-le, inonder l'Europe, voire le monde de notre liqueur verte.

Le premier problème que nous avons, c'est que l'application ne démarre même pas, il semble qu'il y ait une dépendance cyclique entre des composants gérant les commandes (Order) et le paiement (Payment).

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

orderController defined in file [./spring-modulith-workshop/build/classes/java/main/org/snowcamp/university/springmodulith/order/api/web/OrderController.class]
┌─────┐
|  orderManager defined in file [./spring-modulith-workshop/build/classes/java/main/org/snowcamp/university/springmodulith/order/domain/OrderManager.class]
↑     ↓
|  paymentHandler defined in file [./spring-modulith-workshop/build/classes/java/main/org/snowcamp/university/springmodulith/payment/domain/PaymentHandler.class]
└─────┘


Action:

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

Le deuxième problème rencontré, c'est que nos utilisateurs n'arrivent pas passer de commandes ; il semble qu'il y ait un problème lors du paiement.
Essayez d'aller jusqu'au paiement complet... Ça coince. Nous savons que le problème est apparu quand notre père supérieur a insisté pour voir développer une fonctionnalité permettant d'être notifié des commandes complétées. Le site ne permettait même pas de mener une commande complète mais il fallait développer la notification du paiement de commande... Nous ne reviendrons pas sur cette gestion des priorités, mais s'il vous plaît, pourriez-vous faire en sorte que les notifications n'empêchent pas le traitement principal ?

java.lang.RuntimeException: No greeting !!!
at org.snowcamp.university.springmodulith.greeting.configuration.GreetingConfiguration.lambda$noGreeterClient$1(GreetingConfiguration.java:29)
at org.snowcamp.university.springmodulith.greeting.domain.GreeterService.greet(GreeterService.java:25)
...
at org.snowcamp.university.springmodulith.greeting.domain.GreeterService$$SpringCGLIB$$0.greet(<generated>)
at org.snowcamp.university.springmodulith.order.domain.OrderManager.paymentComplete(OrderManager.java:101)
...
at org.snowcamp.university.springmodulith.order.domain.OrderManager$$SpringCGLIB$$0.paymentComplete(<generated>)
at org.snowcamp.university.springmodulith.payment.domain.PaymentHandler.paymentComplete(PaymentHandler.java:22)
...
at org.snowcamp.university.springmodulith.payment.domain.PaymentHandler$$SpringCGLIB$$0.paymentComplete(<generated>)
at org.snowcamp.university.springmodulith.payment.api.web.PaymentController.paymentComplete(PaymentController.java:22)
...

Dans notre appel d'offre, nous avions demandé à Frère Bernard d'utiliser Spring Modulith pour garantir la modularisation de notre application. Nous avons des projections de croissance à l'international ambitieuses et il n'est pas exclu que nous découpions notre backend en micro services par la suite.

Il semble que la dépendance Spring Modulith soit commentée, pourriez-vous l'activer (sans observabilité ni message vers système externe pour l'instant) ?

Une fois Spring Modulith ajouté, vous allez pouvoir étudier la structure actuelle du projet.

Faites en sorte de visualiser les modules actuellement découverts par Modulith, voire d'en générer une documentation.

ApplicationModules.of(ChartreuseShopApplication.class);

Vous devriez également pouvoir évaluer la modularité de l'application en ajoutant un Test dans ChartreuseShopApplicationTest qui fait

ApplicationModules.of(ChartreuseShopApplication.class).verify();

Pourquoi échoue-t-il? Pourriez-vous résoudre les problèmes remontés?

Nous avons constaté que Frère Bernard avait créé un package common, cela risque de poser un problème si ce dernier est considéré comme un module.

Il serait certainement plus sage de l'omettre du scanning...

Pour celà, créez un Bean qui implémente l'interface ApplicationModuleDetectionStrategy.

En lisant la documentation de Spring Modulith, nous avons lu qu'il était préconisé d'opter pour une approche évènementielle pour ce qui est de la communication entre les modules.

Vous devriez pouvoir cloisonner les packages en procédant ainsi :

• créez des objets évènements applicatifs sur les order
• servez-vous de ApplicationEventPublisher pour les publier (Bean disponible dans le contexte d'applicationn spring)
• annotez des méthodes de Component spring avec en paramétre une instance de ces évènements. Plusieurs annotations existent
  • EventListener (avec éventuellement Transactionnal) pour créer un listener synchrone (qui s'insèrera éventuellement dans la transaction parente)
  • TransactionalEventListener pour créer un listener qui recevra l'événement en fin de transaction uniquement si la transaction est réussie (possibilité de régler la phase de commit)
  • ApplicationModuleListener qui fait la même chose que le précédant, avec en plus une exécution asynchrone et une transaction dédiée

À la fin de cet exercice le test de l'étape 3 doit passer au vert.

Lorsque nous avons dit à Frère Bernard de tester le produit, il était clair pour nous qu'il s'agissait de s'assurer du bon fonctionnement de l'application et par la suite de prévenir les régressions. Nous n'imaginions pas que ce dernier testerait tous les jours que Dieu fait la qualité gustative de nos Chartreuses Jaune, Verte et AOP.

Nous avons pensé de commencer par garantir le comportement du module qui s'assure de la commande, à savoir le module order. Pour ce faire, créez une classe de tests annotée ApplicationModuleTest dans laquelle vous écrirez deux tests :

• écrivez un premier test qui prend en paramètre events de type AssertablePublishedEvents qui doit
  • initialiser un Order en base avec un statut en IN_PAYMENT
  • appeler la méthode paymentComplete sur l'attribut de la classe de test OrderManager annoté Autowired
  • faire un assertThat(events)... pour vérifier qu'un évènement est bien publié avec le bon id
• écrivez un autre test qui prend un objet de paramètre de type Scenario. Le test est similaire sauf qu'au lieu d'appeler une quelconque méthode d'OrderHandler on doit
  • publier un event qui signale que la commande est payée
  • tester qu'un event de commande complète a été émis avec le bon id

Pouvez vous jouer avec les Bean CompletedEventPublications et IncompleteEventPublications et purger les évènements et les rejouer ?

Sinon, il paraît qu'il y a un paramètre pour les rejouer au démarrage (sous spring.mod...).

Les moines en charge de la gestion des stocks aimeraient recevoir un message qui leur signifie le nombre de bouteilles commandées pour chaque type.

Ils possèdent déjà un système de messaging et voudraient que notre système pousse un message contenant :

• le type de chartreuse
• le nombre de bouteilles

Pour ce faire, rajouter les dépendances et publier

• un objet annoté de l'annotation @Externalized.
• On peut même éventuellement paramétrer la clef de manière dynamique ; par exemple, dans la déclaration :

@Externalized("example::#{#this.name().toLowerCase()}") 
record MonExample(String name){}

L'objet new MonExample("YouPi") sera publié sur le topic example avec la clef youpi.

Les moines en charge des stocks vous ont monté un environnement de développement à l'image de leur système en production.

Pour vous y connecter :

docker compose exec -it kafka bash

Vous pouvez suivre les messages publiés sur un topic donné, ici par exemple sur le topic example

 /bin/kafka-console-consumer --bootstrap-server localhost:9092 --topic example --from-beginning

Nos moines en charge de l'exploitation sont tout excités après avoir assisté à une présentation OpenTelemetry et ont monté une petite infrastructure permettant la collecte de traces applicatives. Pour vous aider, à l'image des moines en charge des stocks, ils vous ont construit une petite infrastructure pour collecter les traces applicatives.

Pourriez-vous remonter les traces applicatives et les observer dans Grafana?

L'interface de Grafana est accessible à http://localhost:3000/.

Vous pouvez désormais générer la documentation finale afin de constater l'évolution de la structure du projet.

@Test
void generateDocumentation() {
    ApplicationModules modules = ApplicationModules.of(ChartreuseShopApplication.class);
    new Documenter(modules).writeDocumentation();
}