You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- it uses JPA, Spring Security, Spring Batch, and Spring Rest
6
+
- it connects to a Postgres database
7
+
- flyway is used for database migrations
8
+
9
+
# Language usage
10
+
- Do not add comments and null checks unless asked
11
+
- Check Java version from .java_version
12
+
- always add new methods at the end of the file
13
+
14
+
# Code organization
15
+
- Repository and domain code goes in avni-serer-data module.
16
+
- Service, controller, mapper, and dto code goes in avni-server-api module. Flyway migrations are in this module.
17
+
18
+
# Building blocks (or where to put which type of code)
19
+
- There are following building blocks for request processing - Controller, Service, Mapper, Repository, and DTO.
20
+
- Batch jobs use Tasklet/Job - which inturn should use Writer or Service
21
+
- DTOs are of three types - Request, Response, and Contract.
22
+
- Repository should have only basic database operations directly using JPA for single entity type usually. Repository should be responsible for calling external services like Metabase, S3, etc.
23
+
- Service should have all the business logic. It can have mapper, repository, or other services
24
+
- Mapper should map between domain objects and DTO objects and vice versa
25
+
- take request in a typed dto and return response in a typed dto
26
+
- use BaseRepository always and getPrisma method from it
27
+
- the web response contract classes are called Response
28
+
- Mapper should use Repository and not Service
29
+
- Controller can use Service or Repository depending on the complexity of the operation
library.datetime = Use Joda Time (org.joda.time) instead of java.time for all date and time handling, Maintain consistent date formatting patterns across the codebase
coding.comments = add only when explicitly requested
111
+
coding.nullchecks = add only when explicitly requested
112
+
coding.javaversion.check = .java_version
113
+
coding.methodplacement = add new methods at end of file
114
+
115
+
# Documentation Guidelines
116
+
documentation.principles = Avoid JavaDocs in favor of self-documenting code, Use clear method and variable names that explain their purpose, Only add inline comments for complex logic that cannot be made clear through refactoring, Do not document what the code does (it should be obvious), Document why certain decisions were made when not obvious
117
+
118
+
# Refactoring Guidelines
119
+
refactoring.documentation = Avoid JavaDocs, coding style preferred is single-line format, rely on self-documenting code and clear naming instead
modularity.principles = Create small, focused methods with a single responsibility, Limit method size to improve readability and testability, Extract complex logic into separate utility classes, Use immutable objects wherever possible, Avoid deep nesting of methods and control structures
173
+
174
+
# Service Layer Principles
175
+
service.principles = Follow the Single Responsibility Principle, Inject dependencies rather than creating them, Use interfaces for service contracts, Keep business logic in service layer not controllers, Validate input parameters at service boundaries
176
+
177
+
# Repository Layer Principles
178
+
repository.principles = Use Spring Data interfaces where possible, Create custom queries with JPQL or native SQL when needed, Avoid N+1 query problems, Use pagination for large result sets, Consider using query projections for performance
179
+
180
+
# Controller Layer Principles
181
+
controller.principles = Keep controllers thin, Delegate business logic to services, Use DTOs for request/response objects, Implement proper error handling, Document APIs with OpenAPI/Swagger
182
+
183
+
# Domain Model Guidelines
184
+
domain.principles = Use rich domain models, Encapsulate business rules within domain objects, Validate domain invariants, Use value objects for immutable concepts, Consider using domain events for cross-aggregate communication
185
+
186
+
#----------------------------------------------
187
+
# TESTING
188
+
#----------------------------------------------
189
+
# Testing Patterns
190
+
testing.unitTestPattern = **/*Test.java
191
+
testing.integrationTestPattern = **/*IT.java
192
+
testing.coverageThreshold = 70
193
+
194
+
# Testing Principles
195
+
testing.principles = Write tests for all new code, Follow the Arrange-Act-Assert pattern, Use meaningful test names that describe behavior, Mock external dependencies, Test edge cases and error conditions
0 commit comments