- Clean Architecture
- Unit tests with JUnit and Mockito for http and gateway layers
- BDD tests with Spock for usecase layer
- JaCoCo to validate and check testing code coverage
- Formatting code with Google Style guide inside IDE
- Checking code good practices with SonarQube using with Intellij plugin
- Checking code good practices with FindBugs using Intellij plugin
- Executing Mutation test
- Checking all together submitting the application locally to SonarQube
- Handling Exceptions
This application should follow the rules:
- A User must have more than 30 years
- A user cant be created without a name, age and CPF
- The username size must be at least 2 and start with letter Z.
- Given a valid user, it should be stored for latter use
- There should be a way to update a user
- There can be more than one user with same CPF
- When updating an user, the same rules of creations applies.
- Ask :) Let's discuss and then improve this documentation together.
- Must define the correct rest verb:
GET --> Retrieving elements.
PUT --> Updating an existing element
POST --> Create a new element
POST --> Can also be used to retrieve data with a @RequestBody (sometimes a complex consuting may need to pass a Body. Since Get doesn't accept body, use Post for convention)
PATCH --> To partially update of an Element
DELETE --> To remove one element - Must perform Bean Validation of the incoming Payload (Json/DataContract object)
- After validate the incoming payload, Must Convert the incoming payload for a Domain object and pass the domain object to the usecase for processing
- Must document with Swagger all the services (input, output and possible error codes)
- Must NOT have access to other gateways.
- Must be unit tested using JUnit, Mockito and MockMVC
- Depending of the exposed service, it may need to configure security
- May log (beware for sensitive data) the incoming payload
- Must always convert the Domain object returned from the usecase execution to a new object (json/data contract)
- Always return one ResponseEntity wrapping the response object (json/data contract) along with the correct status code (200, 201, 404, 500 etc)
- Must define the consumed and produced data accepted (produces/consumes annotations)
- Depending on the data volume, work with pagination
- Depending on the business, it might be also need Integration Testing
- May log (beware for sensitive data) the incoming payload
- Must perform business rules and validations
- May use another usecase(s) (through constructor injection)
- May use 1 or more Gateways (through constructor injection using ALWAYS an interface and never the concrete implementation)
- Must be EXTENSIVELY tested with Spock testing framework
- Must be responsible for a single operation (for example: CreateUser, PayOrder, ReturnOrder)
- Must have only ONE public method
- Always check the existence of a Controller Advice to handle possible exceptions thrown from the usecase or other layers of the code (the client should not never receive unpredicted exceptions)
- Always check the spring boot doc at: Spring Boot 2.1.3 reference guide
- In case of legacy code, check this website with good refactoring strategies and practice exercises: Refactoring
- Reference sites of Clean Architecture (btw: Hexagonal Architecture is a very similar to Clean Architeture)
- Uncle Bob - Robert Martin: Clean Architecture
- Clean Architecture For The RestOf Us: CLEAN ARCHITECTURE FOR THE REST OF US
- GitHub Code Example: GitHub Code Example
- Anther approach to use Clean Architecture: GitHub Example
- Testing Strategies in microservices: Testing Strategies