J'ai participé au JJUG CCC printemps 2019 qui s'est tenu le 18 mai 2019. Voici un résumé des séances que j'y ai entendues et de leurs impressions.
Cela peut être difficile à voir dans les balles, mais pardonnez-moi s'il vous plaît.
Je vous serais reconnaissant si vous pouviez signaler des erreurs.
Aperçu de la session de participation et impressions
Jakarta EE Update -May 2019-
Document d'information
Aperçu
- L'histoire de Jakarta EE
--Java EE est une marque d'Oracle et ne sera plus disponible
- Le standard a été repris de Java EE à Jakarta EE
- Modifications lors du passage de Java EE à Jakarta EE
- Owner: Oracle -> Eclipse Foundation
--Standardisation: JCP-> JESP
--Spécifications: JSR-> Projet EE4J
--Nom du paquet: javax. * -> Jakarta. *
- L'ancienne API javax. * Peut être utilisée même après être devenue jakarta. *
--Jakarta EE 8 est presque identique à Java EE 8
--Plusieurs changements d'API dans Jakarta EE 9
--Ancien javax. * L'API reste pour la compatibilité
- Si vous transférez à Jakarta EE, la vitesse de développement sera plus rapide que dans Java EE.
――Ce blog sera utile
Impressions
- Puisque le javax. * Le nommage ne sera plus disponible à l'avenir, il peut être un peu gênant de modifier le code existant.
- La vitesse de développement sera plus rapide qu'à l'ère de Java EE, alors attendez-vous
CI l'architecture des applications Java / Kotlin avec ArchUnit
Document d'information
Aperçu
- Une histoire sur le test de l'architecture interne
--ArchUnit est un framework de test qui peut exprimer les dépendances de package sous forme de code de test JUnit.
――Jusqu'à présent, la connaissance de l'architecture a été personnalisée et implicitement informée, et seuls ceux qui la connaissent pouvaient la vérifier.
- Avantages de l'introduction d'ArchUnit
- La revue de l'architecture peut être automatisée
--Peut formaliser la connaissance implicite de l'architecture
- Vous pouvez également tester des règles d'implémentation spécifiques à l'application
- Par exemple, vous pouvez rédiger un test qui garantit que vous passerez la certification.
Impressions
――Si l'architecture n'est pas respectée, elle a tendance à s'endetter, c'est donc merveilleux de pouvoir le garantir!
――Une fois la structure du package décidée, le test de dépendance du package peut être utilisé pendant longtemps une fois qu'il est incorporé, donc j'ai senti qu'il n'y avait pas beaucoup de problème à écrire le test.
--Spring @ PreAuthorized peut être utilisé pour éviter d'oublier d'annoter
Environnement de développement et infrastructure d'application à l'ère du Cloud Native
Document d'information
Aperçu
--Introduction à Eclipse Che
- IDE basé sur un navigateur
--Fournit un environnement de conteneur pour Docker et Kuebernetes
- Fournir IDE, fichiers et environnement sous forme de pods
―― "Cela fonctionne sur mon PC ..." disparaît
――Si vous voulez le toucher, ce qui suit est bon
- Che on OpenShift Online
- Minishift
- OpenShift basé sur Minikube
- Sélectionnez et développez un environnement déjà préparé appelé Stack
--Runtime, compilateur, outils, etc.
- Vous pouvez partager un espace de travail existant à l'aide d'une URL émise par lyophilisation.
- Red Hat fournit activement des plug-ins VS Code pour améliorer l'EDI
Impressions
――Impression que l'apparence est presque la même qu'un IDE général
«Je pensais que ce serait formidable si je pouvais l'utiliser car je pourrais réduire le temps nécessaire pour créer l'environnement de développement.
―― Comme vous ne resterez pas coincé dans la construction d'un environnement, ce type de stress disparaîtra.
Faites progresser le développement! Architecture propre avec Java - Nouveau développement à partir de zéro
Document
Aperçu
- Histoire d'architecture propre
- Le problème qu'il était nécessaire de faire un prototype avant d'abord dans un nouveau développement a été résolu en introduisant une architecture propre afin que la logique et le côté puissent être facilement remplacés.
--Avant l'architecture propre À propos de l'architecture hexagonale
-Hexagonal un
- Rendre échangeable sauf pour la logique métier (Pragapuru)
- Ne pas entremêler la logique métier
- L'architecture propre est une version détaillée de l'implémentation concrète en dehors de l'architecture hexagonale.
«L'architecture d'Onion parle de l'intérieur (application) de l'architecture hexagonale.
- Nettoyer les couches d'architecture
- Enterprise Business Rules
- Application Business Rules
- Interface Adapters
- Controllers
- Presenters
- Gateways
- Frameworks & Drivers
- La direction de la dépendance est vers l'intérieur, donc le code interne ne doit pas faire référence au code externe
--Problèmes avec une architecture propre
--Problème selon lequel Presenter ne peut pas être utilisé avec MVC Framework
- Le présentateur ne peut pas être utilisé car le contrôleur doit renvoyer une valeur
- En fin de compte, j'ai abandonné Presenter (renvoie la valeur dans Controller docilement)
--Controller devient Fat for view, mais c'est OK car la logique de domaine est protégée
- Trop de problèmes de champs
- Puisque les champs de chaque interateur sont injectés, il y a plus de champs.
- Résolu par le modèle de bus de messages
- Enregistrez le processus à l'avance, et le processus correspondant sera effectué en fonction des données transmises.
- Trop de problèmes de définitions
- Trop de choses à définir
--Créez votre propre outil d'échafaudage et résolvez-le (un outil appelé NORIO)
Impressions
- L'architecture propre est décidée en détail, donc si vous la suivez, vous pouvez écrire du code propre.
――Il y a un sentiment qu'il est décidé d'être serré, donc le degré de liberté semble être un peu faible
--Impression que le nombre de classes à créer est susceptible d'augmenter lors de la mise en œuvre
――Il y a des parties qui sont liées à DDD, donc je dois étudier. ..
Division BFF / Backend de l'API pour les applications mobiles dans Hot Pepper Beauty
Aperçu
- L'histoire de la division entre BFF et Backend
- BFF = Backends For Frontends
- Serveur backend situé entre Frontend et API
- Si la source d'accès est un navigateur, elle peut être divisée en HTML, et s'il s'agit d'une application, elle peut être divisée en JSON.
- La vitesse de développement de l'API de l'équipe Backend était lente et l'équipe de l'application était en difficulté.
--Augmentez la vitesse de développement d'API en créant BFF
- La couche BFF est la responsabilité de l'équipe de l'application
- Regroupement et retour de plusieurs API dans la couche BFF
- Actuellement, 6 des 24 API backend peuvent être réutilisées dans la couche BFF.
- Lorsque les performances de l'ensemble de l'API sont élevées, le problème N + 1 de la version de l'API ne se produit pas.
- Conception d'API
- BFF
--Créé pour chaque cas d'utilisation d'application
- Avec gestion des versions
- À moins que l'application ne soit mise à jour, il n'y a pas d'autre choix que de la version parce qu'elle utilise l'ancienne API.
- Pas de versioning
――Parce qu'il est appelé uniquement de l'intérieur
--Lorsque la compatibilité descendante est rompue, répondez en coopération avec BFF
--La technologie
- BFF
- Kotlin
- Spring Boot 2(Spring WebFlux)
- WebFlux a été adopté qui prend en charge les E / S non bloquantes afin que l'attente d'E / S ne se produise pas car plusieurs API sont appelées.
- Backend
- AdoptOpenJDk11
- Spring Boot 2(Spring Mvc)
--Architecture
- BFF
--Seulement couche d'application et couche de domaine
- Jugement que BFF n'a pas besoin d'un modèle de domaine
--Modèle de domaine Sujet à l'anémie
--Appeler l'API de Backend à la couche de domaine de BFF
- Couche d'application, couche de domaine, couche d'infrastructure
- Puisque la couche de présentation devient plus mince en la séparant de BFF, elle est intégrée à la couche d'application.
- Tâche
- Charge élevée sur le backend
- S'il y a un changement, il doit être partagé de BFF vers Backend.
Impressions
――Je pensais que cela pouvait être efficace lorsqu'il y avait plusieurs sources d'affichage telles que les applications et le Web, et que l'équipe de l'application et l'équipe du backend étaient séparées.
Si non, l'impression est que le coût de fabrication d'une meilleure amie est élevé et que vous pourriez en souffrir.
«Cela n'a rien à voir avec BFF, mais la technologie utilisée est relativement nouvelle et enviable.
Points clés de la migration des micro-services par modèle étranger
Document d'information
Aperçu
- Une histoire sur le remplacement progressif du système hérité par un modèle plus étrange
--Jusqu'à maintenant (héritage)
--Java est sur la VM
--Sur-pré-Oracle
--Utiliser le cadre d'origine
--Après renouvellement
- Division des services par micro-service
- La passerelle API est prise en sandwich entre Azure API Management
- Tout d'abord, créez un service après le renouvellement dans Azure, puis dirigez le service existant vers le service renouvelé pour chaque fonction, et enfin déplacez la base de données du côté on-pre vers Azure
--La technologie
- Open API
- Spring Boot
- Azure Kubernetes Service
- Azure API Management
- Swagger Codegen génère automatiquement des bibliothèques d'appels API pour les systèmes hérités et les systèmes renouvelés.
- Agrégation de journaux avec Papertrail
- Traçage distribué avec Spring Cloud Sleuth
Impressions
«Je pensais que le modèle Strangler était très efficace pour le renouvellement de l'héritage au moderne.
――Je sympathise avec la transition progressive
- C'est incroyable que Swagger génère automatiquement une bibliothèque.
- Il existe différents outils d'agrégation de journaux, nous allons donc les vérifier la prochaine fois.
Functional Spring Cookbook
Document d'information
Aperçu
- L'histoire que je l'ai écrite comme un type de fonction au printemps
--Spring WebFlux vous permet d'écrire des applications Web en ** Easy ** sur une base d'annotations
--Spring WebFlux.fn vous permet d'écrire des applications Web en ** Simple ** de manière fonctionnelle
--Spring WebMvc.fn peut être écrit sous une forme fonctionnelle comme Spring WebFlux.fn, mais le traitement devient synchrone.
- Présentation de différentes façons d'écrire des définitions de Bean, un client HTTP, etc. dans Spring WebFlux.fn et Spring WebMvc.fn
- Présentation de la façon de remplacer
@ SpringBootApplication par une implémentation scratch de Spring WebFlux.fn ou Spring Fu
Impressions
―― Puisque vous pouvez écrire dans un style fonctionnel, j'ai trouvé que c'était merveilleux de pouvoir écrire simplement avec un peu de description.
Dans le cas d'un service à grande échelle qui introduit une architecture propre, etc., il y a un processus pour appeler la couche application, donc j'ai senti que la méthode de routage deviendrait Fat et ce serait difficile à voir et simple.
(Mis à jour le 20 mai 2019 ↓)
«Nous avons reçu un commentaire direct de @making @ github, et il a dit qu'il n'aurait aucun problème car il pouvait synthétiser des routes.
-Si vous lisez Documentation, vous constaterez que RouterFunction Mapping est plusieurs RouterFunction < Il semble synthétiser des beans de type?>, Donc vous pouvez diviser la méthode de routage.
--L'implémenteur n'a besoin que de définir plusieurs Beans de type RouterFunction <?> Sans en avoir conscience.
――Si tel est le cas, gardons les choses simples sans devenir gros