I participated in JJUG CCC 2019 Spring held on May 18, 2019. This is a summary of the sessions I heard there and their impressions. It may be hard to see in the bullet points, but please forgive me. I would appreciate it if you could point out any mistakes.
Jakarta EE Update -May 2019-
--The story of Jakarta EE --Java EE is a trademark of Oracle and will no longer be available --The standard was taken over from Java EE to Jakarta EE --Changes when changing from Java EE to Jakarta EE - Owner: Oracle -> Eclipse Foundation --Standardization: JCP-> JESP --Specifications: JSR-> EE4J Project --Package name: javax. *-> jakarta. * --The old javax. * API can be used even after becoming jakarta. * --Jakarta EE 8 is almost the same as Java EE 8 --Several API changes in Jakarta EE 9 --Old javax. * API remains for compatibility --If you transfer to Jakarta EE, the development speed will be faster than in Java EE. ――This blog will be helpful - Jakarta Blogs
--Since the name of javax. * Will not be available in the future, it may be a little troublesome to modify the existing code. --The development speed will be faster than in the Java EE era, so expect it.
--A story about testing the internal architecture --ArchUnit is a test framework that can express package dependencies as JUnit test code. ――Until now, the knowledge of architecture was personalized and tacit knowledge, and only those who knew it could check it. --Advantages of introducing ArchUnit --Architecture review can be automated --Explicit knowledge of architecture can be explicit knowledge --You can also test application-specific implementation rules --For example, you can write a test that guarantees that you will pass the certification.
――If the architecture is not followed, it tends to cause some debt, so it is wonderful to be able to secure this!
――Once the package structure is decided, the package dependency test can be used for a long time once it is incorporated, so I felt that there was not much trouble writing the test.
--Spring @PreAuthorized can be used to prevent forgetting to annotate
--Introduction to Eclipse Che --Browser-based IDE --Provides a container environment for Docker and Kuebernetes --Providing IDE, files and environment as pods ―― "It works on my PC ..." disappears ――If you want to touch it, the following is good - Che on OpenShift Online - Eclipse Che | Eclipse Next-Generation IDE, Cloud IDE, and Workspace Server - Minishift --Minikube-based OpenShift --Select and develop an already prepared environment called Stack --Runtime, compiler, tools, etc. --You can freeze existing Workspace and share it using the URL issued. --Red Hat is actively providing VS Code plugins to enhance the IDE
――Impression that the appearance is almost the same as a general IDE ――I felt that it would be great if I could use it because I could cut the time to build the development environment. ――Since you won't get stuck in building the environment, that kind of stress will disappear.
-Practical clean architecture with Java │ nrslib
--Clean architecture story --The problem that it was necessary to make a prototype of the front in new development was solved by introducing a clean architecture and making it possible to easily replace the logic and the side. --Before clean architecture About hexagonal architecture --Hexagonal one --Make exchangeable except for business logic (Pragapuru) --Do not intersperse business logic --Clean architecture that details the concrete implementation outside the hexagonal architecture ――Onion architecture is talking about the inside (application) of hexagonal architecture. --Clean architecture layers - Enterprise Business Rules - Entities - Application Business Rules - Use Cases - Interface Adapters - Controllers - Presenters - Gateways - Frameworks & Drivers - UI - DB etc --The direction of the dependency is inward, so the inner code must not refer to the outer code --Problems with clean architecture --Problem that Presenter cannot be used with MVC Framework --Presenter cannot be used because Controller must return some value --In the end, I abandoned Presenter (returns the value in Controller obediently) --Controller becomes Fat for view, but domain logic is protected, so OK --Too many fields problem --Since the fields for each Iterator are injected, there are more fields. --Resolved by Message Bus pattern --Processing is registered in advance, and the corresponding processing is performed according to the passed data. --Too many definitions problem --Too many definitions --Create your own scaffolding tool and solve it (a tool called NORIO)
--The clean architecture is decided in detail, so if you follow it, you can write clean code. ――There is a feeling that it is decided to be tight, so the degree of freedom seems to be a little low --Impression that the number of classes to be created is likely to increase when it comes to implementation ――There are some parts that are related to DDD, so I have to study. ..
--The story of splitting between BFF and Backend
――I thought that it might be effective when there are multiple display sources such as apps and the Web, and the app team and backend team are separated. ――If not, the cost of making BFF is high, and the impression is that you will suffer. ――It has nothing to do with BFF, but the technology used is relatively new and enviable.
--A story about gradually replacing the legacy system with a strangler pattern --Until now (legacy) --Java is listed in the VM --On-premise Oracle --Use the original framework --After renewal --Service split by microservices - Azure Kubernetes Service --A API Gateway is sandwiched between Azure API Management --First, create a service after renewal in Azure, then direct the existing service to the renewed one for each function, and finally move the DB from on-premise to Azure side --Technology - Open API - Spring Boot - Azure Kubernetes Service - Azure API Management --Swagger Codegen automatically generates API call libraries for legacy systems and renewed systems --Log aggregation with Papertrail --Distributed tracing with Spring Cloud Sleuth
――I thought the Wrangler pattern was very effective for the renewal from legacy to modern. ――I sympathize with the gradual transition --It's amazing that Swagger automatically generates a library. --There are various log aggregation tools, so let's check them out next time.
Functional Spring Cookbook
-Functional Spring Cookbook --Google Slide
--The story that I wrote it like a function in Spring
--Spring WebFlux allows you to write web apps in ** Easy ** based on annotations
--Spring WebFlux.fn allows you to write web apps in ** Simple ** in a functional way
--Spring WebMvc.fn can be written in a functional form like Spring WebFlux.fn, but the processing becomes synchronous.
--Introducing various ways to write Bean definitions, HTTP Client, etc. in Spring WebFlux.fn and Spring WebMvc.fn
--Introducing how to replace @SpringBootApplication with Spring WebFlux.fn scratch implementation or Spring Fu
――Since you can write functionally, I felt that it was wonderful to be able to write simply with a small amount of description. ――In the case of a large-scale service that introduces a clean architecture etc., there is a process to call the application layer, so I felt that the routing method would become Fat and it would be difficult to see and simple.
(Updated on May 20, 2019 ↓)
--- @ making @ github commented directly, and you can synthesize routes, so there is no problem so much. -When you read Document, there are multiple RouterFunctions called RouterFunction < Since it seems to synthesize beans of type?>, You can split the routing method. --The implementer only needs to define multiple RouterFunction <?> Type Beans without being aware of it. ――If this is the case, let's keep it simple without becoming Fat
Recommended Posts