Comment concevoir et architecturer une application Web Java / Java EE?
Je suis Java avec près de 5 ans d'expérience sur Struts, Spring et Hibernate.
Nous avons un nouveau projet à venir dans quelques jours. Nous avons les exigences complètes avec nous et nous réaliserons ce projet en utilisant Spring MVC, Spring et Hibernate.
On m'a demandé de concevoir et d'architecturer l'ensemble de l'application Web. Concevoir et créer un architecte est quelque chose que je n'ai pas fait jusqu'à présent dans ma carrière. Et je ne sais pas comment procéder et où commencer, quels outils utiliser, etc. Je ne connais même pas les A, B, C du design et de l'architecture.
Vous vous demandez peut-être pourquoi j'ai même été invité à le faire en premier lieu. Le truc, c'est que j'ai eu l'occasion de le faire et à chaque étape, je serai surveillé et je demanderai à mes aînés de revoir la conception.
Donc, toute suggestion, idée et étape pour commencer et continuer est la bienvenue.
Je peux ajouter mes 2 cents de mes propres expériences (bien qu'il s'agisse plutôt d'une compilation des meilleures pratiques de développement, vous pourriez trouver utile de les garder à l'esprit lors de la conception de votre application):
- Il n'y a pas de conception unique
- Essayez de garder l'application aussi légère que possible.
- Utilisez Maven/Gradle pour gérer les dépendances
- Ne vous fiez pas trop à l'IDE. Assurez-vous que votre projet se construit sans IDE (Si vous utilisez maven/gradle, il va :) Essayez d'ouvrir votre projet avec IDEA, Netbeans et Eclipse.
- Pour les technologies mentionnées ci-dessus, appfuse constitue un bon point de départ.
- Concevez d'abord votre base de données/entités
- Utilisez les bibliothèques de manière sensée et judicieuse. Ne les abusez PAS.
- N'oubliez pas d'écrire JUnit/TestNG (au moins pour la couche service)
- Testez l'application sur tous les principaux navigateurs (pas seulement votre préféré :)
- Déterminez le nombre total d'utilisateurs et le nombre d'utilisateurs simultanés de votre application Web.
- Décidez ensuite si vous avez besoin de la mise en cache ou non.
- vous utiliserez ou non le clustering de serveurs d'applications.
- Sélectionnez le serveur d'applications en fonction de ses capacités et, surtout, de "vos besoins"
- Tomcat/Jetty sont absolument parfaits pour la plupart des cas
- Évitez d'utiliser une API spécifique au serveur d'applications
- Utilisez les interfaces/annotations JPA même si vous utilisez hibernate comme implémentation JPA
- Soyez extrêmement prudent lors de la cartographie des relations dans les entités. Décidez quelles propriétés et relations se chargeront paresseusement et lesquelles se chargeront avec impatience
- Gardez à l'esprit la sécurité des applications lors de la conception de l'application. La sécurité du printemps est un excellent choix.
- N'abusez jamais de HttpSession. Ne stockez pas trop dedans.
- Gardez les entités sérialisables. Imposer aux développeurs d'utiliser toString (), hashCode () et equals ()
- N'oubliez pas d'utiliser le contrôle de version à partir du jour 1
- Ne présumez pas simplement que spring/hibernate/spring-mvc sera le meilleur choix pour vous. créer une petite preuve de concepts avec au moins 3 à 4 options.
- Essayez d'automatiser l'intégration/la construction/le déploiement avec des outils CI comme Jenkins
- Vérifier et régler le SQL généré par Hibernate (de temps en temps)
- Ne laissez pas la logique métier se glisser dans la couche de vue. Vous détestez les scriptlets jsp? Considérez Velocity/Freemarker. JSP n'est pas la seule option.
- externalisez la configuration spécifique à l'environnement à l'aide de PropertyPlaceholderConfigurator de Spring.
- Si possible, essayez d'intégrer le mécanisme d'authentification utilisateur existant (comme LDAP/OpenID) plutôt que d'écrire le vôtre. Cela vous évitera de réinventer la roue et vos utilisateurs de se souvenir d'un autre ensemble de nom d'utilisateur et de mot de passe.
Il y a plusieurs choses dont vous aurez besoin pour les documents de conception d'architecture. Pas une tâche facile mais des accessoires pour saisir l'occasion. Comme il s'agit d'une question si vaste, j'espère que ces liens peuvent vous aider à démarrer et que vous pourrez affiner les questions après vous être mouillé les pieds.
Méthodologie
La méthodologie que vous utilisez affectera les tâches que vous entreprenez en premier. Waterfall est une méthodologie populaire mais obsolète. Une nouvelle méthodologie est Agile qui a plusieurs visages. Mon préféré est Scrum Agile pour développer des logiciels de toute taille.
Diagrammes
Diagrammes sont l'un des moyens les plus puissants de représenter le système dans son ensemble et en tant que composants individuels. Le type de diagrammes que vous créez dépend du système. Il existe généralement des diagrammes de structure, des diagrammes de comportement, des diagrammes d'interaction et des tonnes d'autres. Ces diagrammes montrent les pièces du système dans son ensemble, la disposition physique et/ou la disposition logique de chaque composant, le flux de communication, le flux de procédure, etc.
Documentation
La documentation est comme elle sonne, les documents et les documents qui ont des descriptions de projet, la portée, les cas d'utilisateurs, les diagrammes de séquence et tout autre document qui décrit le projet ou des morceaux du projet.
Jetez un œil à l'architecture propre de Robert Martin (alias Oncle Bob). Voici un aperçu rapide. En utilisant cette approche, vous serez capable de reporter des détails comme Spring ou Hibernate à une date ultérieure et vous concentrer davantage sur la logique métier. Ou même migrez de Spring vers Java EE sans toucher à votre logique métier et d'application. Vous obtiendrez également une application testable qui respecte les principes SOLID, sans trop d'efforts supplémentaires.
Je viens de créer une application de cette façon et je dois dire que j'en suis très content. Je pourrais facilement le porter sur un ordinateur de bureau ou une application mobile, ou échanger le module de stockage. Les détails selon la politique vont un long chemin. Il favorise également la réflexion d'une manière API et, lorsqu'il est appliqué correctement, rend vos modules très réutilisables.
Martin va jusqu'à dire que des détails comme les cadres sont ennuyeux et ne font pas partie de votre architecture. Je pense qu'ils appartiennent à l'architecture, mais juste à un niveau différent. Souvent, vous souhaitez inclure des frameworks à un stade précoce pour être en mesure de produire une fine tranche d'une application fonctionnelle à présenter à vos utilisateurs. Ou quand vous connaissez vos frameworks à l'avance et qu'il n'y a pas de discussion à leur sujet, comme dans mon cas. Mais vous pouvez le considérer comme des architectures logicielles distinctes, lorsqu'elles sont combinées, créez votre architecture d'application.
Parcourez le site de modélisation agile qui préconise la modélisation "juste assez". Ils ont d'excellentes lignes directrices, y compris un "processus de modélisation agile" complet de la collecte des exigences à la conception/développement.
http://www.agilemodeling.com/essays/amdd.htm
http://www.agilemodeling.com/essays/agileArchitecture.htm
http://www.agilemodeling.com/essays/agileAnalysis.htm
http://www.agilemodeling.com/essays/agileDesign.htm
Quant aux outils, j'adore Visual Paradigm. C'est relativement peu coûteux (par rapport à d'autres outils). Il existe une variété d'outils de modélisation gratuits (Google est votre ami), mais aucun ne se compare à Visual Paradigm, et pour un peu que cela coûte, cela en vaut la peine. Si mon employeur ne remettait pas l'argent pour cela, je l'achèterais moi-même ... :)