- Keep in mind rules from Google Java Style Guide.
- Code must be in English.
- The controllers should finish with suffix "Controller". Example: UserController.
- The services should finish with suffix "Service". Example: UserService.
- The repositories should finish with suffix "Repository". Example: UserRepository.
- The interfaces should start with prefix "I". Example: IUserRepository.
- The implementations should finish with suffix "Impl". Example: UserServiceImpl.
- The DTOs should finish with suffix "Dto". Example: UserDto, UserRequestDto.
- Usage of DTOs is a must. Can have DTOs for request and response.
- Package names are in singular.
- The names of attributes/fields from Java classes must be written using camel case. Example: firstName.
- The name of columns in the entities must be written using underscore and uppercase. Example: FIRST_NAME. The name of the tables is always in plural, but the entity name should be in singular.
- Exceptions should be handled by an implementation of ControllerAdvice.
- Messages to user can't be hardcoded them should be handled. Some refs here and here.
- If you add a new endpoint, make sure to set the role access for it in the SecurityConfig class.
You will find an example of how to work with the project architecture in architecture-example
branch.
- Always create the branch from develop
- The branch name format is:
feature/{jiraTicket#}
. - The pull request title format is:
{jiraTicket#}: {jiraTitle}
. - The commits format is:
{jiraTicket#}: {commitDescription}
. Small commits are a nice to have. - The pull request has to contain only the changes related to the scope defined in the ticket.
- Pull request should always be from your current branch to develop.
- If you do not write unit test or integration test as part of your code changes, you should add the HTTP request and response as evidence that the code is working as expected.
- Screenshots from Postman with different scenarios are a good way to show your work.
In the current repository you will see three diferent branches
master
-> this branch is only for productive versions, it has official release history.develop
-> this branch serves as an integration branch for features. All features must start from this branch and after it's finished it gets merged back into develop.architecture-example
-> in this branch you will find an example of a suggested architecture. You can take it as a reference but you should not modify it.
For understanding more about git and how to work with different branches, I recommend to read about Gitflow workflow. Here you have a little explanation that can serve as introduction.
On the root folder run:
mvn spring-boot:run