Maven-Archetypes — a comeback of code templates?
Nowadays, nearly every developer is getting in contact with the term microservice. The Pros of this architecture are obvious:
- individual scaling of each microservice
- small and independent services with a small functional scope
- possibility to use different technologies in different services in a project.
There are a lot of more pros (and of course cons) which have already been discussed in the media. This story focusses on the maintainability of multiple microservices with the help of Maven-Archetypes.
IT Systems are getting more and more complex. Many different technologies and programming languages are used, which may leads to a poorer maintainability. Developers have to be familiar with the versatile technology in order to be able to maintain a project. Thereto the skill requirements of developers increase which may lead companies to desire full stack swiss army like developer.
The idea to use different technologies for microservices collides with the SCRUM principle of having a homogenous team in terms of skillset to compensate absence of team members. Using more or different technologies makes it more difficult to ensure homogenous team.
Preventing technology diversity
From my point of view, an old tool is getting more relevant than ever: Maven-Archetypes. Today you’re creating multiple small services which should have the same general architecture to increase the maintainability. This is the idea behind Maven-Archetypes. Defining a template and generating one or multiple projects (or services) from this template. Using a template ensures, that every microservice initially has the same architectural structure. A developer only has to understand the architecture of a service one time and is able to maintain multiple microservices without the need taking hours to understand how the service is working.
An example microservice Maven-Archetype
Doing the same stuff over and over again is deeply unpopular within the developers community, which leaves the developer with the urge to automate these things to improve his efficiency. I found myself, recreating all the same structure of a typical Spring-Boot rest-service again and again. So I started to create a Maven-Archetype of a Spring-Boot service separated in multiple modules for different purposes.
You can find the archetype in the public archetype catalog
mvn archetype:generate -DarchetypeGroupId=de.bitgrip.archetypes -DarchetypeArtifactId=spring-boot-service -DarchetypeVersion=0.1.0or on github:
https://github.com/bitgrip/spring-boot-archetype
The architecture
The Maven-Archetype creates a Spring-Boot rest-service with a default “Hello World” implementation including database persistence and a generated Feign-Client to use it. To accomplish it and to have a clear separation between the application-layers, the service is highly modularised into six sub-modules:
- API (Controller interface definitions and API DTOs)
- Client (Feign-Client using the API module to generate a client)
- Controller (API implementation and entrypoint to the service)
- Service (Service layer which provides business rule functions)
- Domain (Persistence layer, Spring-Data-JPA repositories and entities)
- Application (Main class and Spring-Boot configurations)
Using this high modularisation has some benefits:
- Possibility to provide a client without any service dependency except the API
- Clear separation of the modules and their responsibilities (Single-Responsibility-Principle)
- Easy testing of each module
- Interchangeable modules e.g. the service
What do you think about archetypes? Are they outdated or are they coming back?
If you want to train your german skills, you could read an additional article about Maven-Archetypes which additionally describes how to create an Maven-Archetype.
If you have any suggestions, improvements or opinions about Maven-Archetypes or especially my example Maven-Archetype, feel free to get in contact or share your thoughts in the comment section below.
Did you like the article? Then donate a few claps or recommend the article to others.
If you want to know more about BITGRIP, our projects or our conference visits, follow us on Twitter @bitgrip_berlin or subscribe to our medium channel and you will get automatic updates on new posts.
