Introduction Spring Modulith
Dernière mise-à-jour : May 2, 2023
Spring Modulith – Spring for the Architecturally Curious Developer
Oliver DROTBOHM - github
Spring nous fournit beaucoup de liberté en terme d’architecture applicatif. Typiquement la plupart des développeurs sépare leur application par unité technique.
org.example.superapp.daoorg.example.superapp.serviceorg.example.superapp.resourceorg.example.superapp.domain
Dans ce genre d’architecture, le package sert seulement à grouper des classes. Les dépendances importants entre les composants sont obligés de passer les limites de leur package.
Le principe SOLID Single Responsability dicte que la vue doit être séparer du controller, cependant, cela ne
signifie pas qu’il doit être dans 2 endroits totalement différent (comme dans des frameworks comme Django, Rails…).
De plus cette contruction ne nous donne pas d’information sur le métier de l’application. Dan North mentionne ce problème et utilise les termes suivant : Domain Based Structure et Domain Based Boundaries.
Donc plutôt que grouper les composants par module technique, nous allons les mettre par unité métier. Pourquoi pas organiser nos packages comme ci-dessous :
org.example.ecommerce.orderorg.example.ecommerce.cardorg.example.ecommerce.inventory
Plus d’information sont disponibles dans le billet de blog de Dan North CUPID for joyful coding.
Order | Inventory | Card | |
Web - | |||
Business Logic - | |||
Data Access - |
Pourquoi pas utiliser le système modulaire du jdk9 :
plus lourd que spring-modulith pour des petites applications