[BOOM-73] [FEAT] 자동차 사고처리 기능 구현

[Gyuwon-Jung]

🎟️ 상위 작업 (Epic Number)

BOOM-69

📝 상세 내용(Description)

자동차 사고처리 관련 기능 구현

✅ 체크리스트(Tasks)

• 자동차 사고 접수 기능 구현
• 자동차 사고 파일 업로드 기능 구현
• 자동차 사고 접수 엔티티 리팩토링

[github-actions]

Jira Issue Created: BOOM-73

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

_{You can configure auto-planning by selecting labels in the issue_enrichment configuration.}

🔗 Similar Issues

Related Issues

• [BOOM-21] [FEATURE] 자동차 사고 관련 파일 엔티티 구현 #19
• [BOOM-22] [FEATURE] 자동차 사고 보상처리 Entity 구현 #20
• [BOOM-20] [FEATURE] 자동차사고 접수 Entity 구현 #18
• [BOOM-71] [FEAT] 제품 개발 API 구현 #77
• [BOOM-59] [refactor] 사고보상처리 엔티티 리팩토링 #63

👤 Suggested Assignees

• Gyuwon-Jung
• chaewoo-kim

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Implementation Plan

Approach

Implement car accident intake registration and file upload features, creating the complete API layer (controllers, services, repositories, DTOs) for submitting accident reports and uploading associated documentation files.

Observations

This is a Spring Boot 3.5.7 application with domain-driven architecture organized by business features. The domain entities AccidentIntakeEntity and AccidentFileEntity already exist but lack supporting infrastructure—no REST controllers, service layer, repository interfaces, or DTOs have been implemented yet. The codebase uses Spring Data JPA with MySQL, stores accident files as TEXT in the database, and has a generic ApiResponse<T> wrapper for API responses. Error handling infrastructure (GlobalExceptionHandler, ErrorCode, CustomException) exists but is not yet implemented.

Assumptions

Assumption 1: File storage strategy for accident files

Options Considered:

• Use AWS S3 for cloud storage (matches ProductFile pattern, scalable)
• Use database TEXT storage (matches existing AccidentFileEntity structure)

Chosen Option: Use database TEXT storage (matches existing AccidentFileEntity structure)

Rationale: This approach respects the existing AccidentFileEntity implementation which already stores file content as TEXT in the database. While S3 would be more scalable for production, changing the storage mechanism would require modifying the existing entity structure and adding S3 configuration. The database storage pattern is already established for accident files and is simpler to implement for this initial feature.

Assumption 2: JPA relationship mapping between entities

Options Considered:

• Add bidirectional relationship with @onetomany in AccidentIntakeEntity and @manytoone in AccidentFileEntity
• Add unidirectional @manytoone relationship only in AccidentFileEntity

Chosen Option: Add unidirectional @manytoone relationship only in AccidentFileEntity

Rationale: This provides the necessary navigation from file to intake while keeping the relationship simple. Bidirectional mapping would add complexity and isn't needed for the current requirements since we don't need to navigate from intake to all files in the initial implementation.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Plan

Phase 1: Data Access Layer & Domain Model

Establish the persistence layer by creating repository interfaces and fixing the entity relationship mapping.

Task 1: Create Repository Interfaces

Create JPA repository interfaces to enable database operations for accident intake and file entities.

• Create AccidentIntakeRepository interface in src/main/java/com/nuclear/boomm/caraccident/repository/ extending JpaRepository<AccidentIntakeEntity, Long>
• Create AccidentFileRepository interface in the same directory extending JpaRepository<AccidentFileEntity, Long>
• Add custom query method List<AccidentFileEntity> findByAccidentIntakeId(Long accidentIntakeId) to AccidentFileRepository for retrieving files by intake ID

Task 2: Fix JPA Relationship Mapping

Properly map the relationship between AccidentFileEntity and AccidentIntakeEntity using JPA annotations.

• Update src/main/java/com/nuclear/boomm/caraccident/domain/AccidentFileEntity.java to change the accidentIntakeId field from a simple @Column to a proper @ManyToOne relationship with @JoinColumn(name = "accident_intake_id")
• Keep fetch type as LAZY to avoid unnecessary data loading
• Ensure the foreign key constraint is properly defined

🤖 Prompt for AI agents

Implement the data access layer for accident intake and file entities.

Create `AccidentIntakeRepository` interface extending
`JpaRepository<AccidentIntakeEntity, Long>`
Create `AccidentFileRepository` interface extending
`JpaRepository<AccidentFileEntity, Long>`
Add custom query method `findByAccidentIntakeId(Long accidentIntakeId)` to
AccidentFileRepository

Update AccidentFileEntity to convert `accidentIntakeId` field from @Column to
@ManyToOne relationship with AccidentIntakeEntity
Use @JoinColumn(name = "accident_intake_id") for proper foreign key mapping
Set fetch type to LAZY

Phase 2: Business Logic Layer

Implement the service layer to encapsulate business logic, validation rules, and transaction management.

Task 1: Create Accident Intake Service

Build the service responsible for registering new accident intake records.

• Create AccidentIntakeService class in src/main/java/com/nuclear/boomm/caraccident/service/ with @Service annotation
• Inject AccidentIntakeRepository via constructor
• Implement createAccidentIntake() method with @Transactional annotation that accepts intake details (accident description, incident date, car number, insured person ID, bank information) and saves the entity
• Set initial status to appropriate value from InsuranceClaimStatus enum (likely a "submitted" or "pending" status)
• Return the created entity with generated ID

Task 2: Create File Upload Service

Build the service responsible for handling accident file uploads and associating them with intake records.

• Create AccidentFileService class in src/main/java/com/nuclear/boomm/caraccident/service/ with @Service annotation
• Inject both AccidentFileRepository and AccidentIntakeRepository via constructor
• Implement uploadAccidentFile() method with @Transactional annotation that validates the intake exists, converts file content to TEXT format, creates AccidentFileEntity with proper relationship to AccidentIntakeEntity, and saves the file entity
• Add business validation to check file size limits, verify intake ID exists before upload
• Return the created file entity with metadata

🤖 Prompt for AI agents

Implement the service layer for accident intake and file upload business logic.

Create `AccidentIntakeService` with @Service annotation
Inject AccidentIntakeRepository via constructor
Implement @Transactional `createAccidentIntake()` method that accepts intake
details and saves the entity
Set initial status from InsuranceClaimStatus enum
Return created entity with generated ID

Create `AccidentFileService` with @Service annotation
Inject AccidentFileRepository and AccidentIntakeRepository via constructor
Implement @Transactional `uploadAccidentFile()` method that validates intake
exists, converts file content to TEXT, creates AccidentFileEntity with
relationship to AccidentIntakeEntity, and saves the file
Add validation for file size limits and intake existence
Return created file entity with metadata

Phase 3: API Layer & DTOs

Create the REST API endpoints, request/response DTOs, and input validation.

Task 1: Define Request and Response DTOs

Create data transfer objects to decouple the API contract from domain models.

• Create AccidentIntakeCreateRequest DTO in src/main/java/com/nuclear/boomm/caraccident/dto/ with fields for accident description, incident date, car number, insured person ID, bank account details, and validation annotations (@NotNull, @NotBlank, @Size, @Pattern for structured data like dates and car numbers)
• Create AccidentIntakeResponse DTO with fields matching AccidentIntakeEntity (id, accident description, status, timestamps) for returning intake details
• Create AccidentFileUploadRequest DTO with fields for accident intake ID, file name, and file content (as String or Base64), with validation annotations
• Create AccidentFileResponse DTO with fields for file ID, file name, upload timestamp, and associated intake ID

Task 2: Create Accident Intake Controller

Build REST endpoints for accident intake registration.

• Create AccidentIntakeController class in src/main/java/com/nuclear/boomm/caraccident/controller/ with @RestController and @RequestMapping("/api/accidents/intake") annotations
• Inject AccidentIntakeService via constructor
• Implement POST endpoint createAccidentIntake(@Valid @RequestBody AccidentIntakeCreateRequest request) that calls service, converts entity to DTO response, and wraps in ApiResponse.success()
• Add @Validated annotation to enable validation
• Map request DTO fields to entity fields and response entity fields back to response DTO

Task 3: Create File Upload Controller

Build REST endpoints for uploading accident-related files.

• Create AccidentFileController class in src/main/java/com/nuclear/boomm/caraccident/controller/ with @RestController and @RequestMapping("/api/accidents/files") annotations
• Inject AccidentFileService via constructor
• Implement POST endpoint uploadFile(@Valid @RequestBody AccidentFileUploadRequest request) that validates the intake exists, processes file content, calls service to save, and returns ApiResponse.success() with file metadata
• Consider adding GET endpoint to retrieve files by intake ID for future use

🤖 Prompt for AI agents

Implement the REST API layer with DTOs for accident intake and file upload.

Create DTOs in the dto package:
- `AccidentIntakeCreateRequest` with fields for accident details and validation
annotations (@NotNull, @NotBlank, @Size, @Pattern)
- `AccidentIntakeResponse` with fields matching AccidentIntakeEntity
- `AccidentFileUploadRequest` with fields for intake ID, file name, and file
content with validation
- `AccidentFileResponse` with file metadata fields

Create `AccidentIntakeController` with @RestController and
@RequestMapping("/api/accidents/intake")
Inject AccidentIntakeService via constructor
Implement POST endpoint `createAccidentIntake()` with @Valid request body that
calls service and returns ApiResponse.success() with DTO
Add @Validated annotation for validation

Create `AccidentFileController` with @RestController and
@RequestMapping("/api/accidents/files")
Inject AccidentFileService via constructor
Implement POST endpoint `uploadFile()` with @Valid request body that validates
intake, processes file, and returns ApiResponse.success() with file metadata

Phase 4: Error Handling Infrastructure

Implement consistent error handling across the accident features.

Task 1: Define Error Codes

Establish error codes specific to accident intake and file upload operations.

• Update src/main/java/com/nuclear/boomm/product/error/ErrorCode.java to define enum values with fields for code (String), message (String), and HTTP status (HttpStatus)
• Add error codes: ACCIDENT_INTAKE_NOT_FOUND (404), INVALID_ACCIDENT_DATA (400), FILE_UPLOAD_FAILED (500), FILE_TOO_LARGE (400), INVALID_FILE_FORMAT (400)
• Provide getter methods for code, message, and status

Task 2: Implement Global Exception Handler

Create centralized exception handling for consistent error responses.

• Update src/main/java/com/nuclear/boomm/product/error/GlobalExceptionHandler.java to add @RestControllerAdvice annotation
• Implement @ExceptionHandler(MethodArgumentNotValidException.class) method to handle validation errors, extract field errors, and return ApiResponse.error() with appropriate messages and 400 status
• Implement @ExceptionHandler(CustomException.class) method to handle business logic exceptions and return ApiResponse.error() with error code message and appropriate HTTP status
• Implement @ExceptionHandler(Exception.class) method as catch-all for unexpected errors, returning generic error message with 500 status

Task 3: Create Domain-Specific Exceptions

Add custom exceptions for accident-related business logic errors.

• Update src/main/java/com/nuclear/boomm/product/error/CustomException.java to accept ErrorCode parameter instead of just message string
• Create AccidentNotFoundException in src/main/java/com/nuclear/boomm/caraccident/error/ extending CustomException for when accident intake ID doesn't exist
• Create FileUploadException for file processing errors
• Throw these exceptions in service layer when business rules are violated (e.g., intake not found, file size exceeded)

🤖 Prompt for AI agents

Implement comprehensive error handling infrastructure for accident features.

Update ErrorCode enum to add accident-specific error codes with fields for code,
message, and HTTP status:
- ACCIDENT_INTAKE_NOT_FOUND (404)
- INVALID_ACCIDENT_DATA (400)
- FILE_UPLOAD_FAILED (500)
- FILE_TOO_LARGE (400)
- INVALID_FILE_FORMAT (400)
Provide getter methods

Update GlobalExceptionHandler with @RestControllerAdvice
Add @ExceptionHandler for MethodArgumentNotValidException to handle validation
errors and return ApiResponse.error() with 400 status
Add @ExceptionHandler for CustomException to handle business logic exceptions
and return ApiResponse.error() with appropriate status
Add @ExceptionHandler for Exception as catch-all returning 500 status

Update CustomException to accept ErrorCode parameter
Create AccidentNotFoundException extending CustomException
Create FileUploadException for file processing errors
Throw these exceptions in service layer when business rules are violated

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the data access layer for accident intake and file entities.

Create `AccidentIntakeRepository` interface extending
`JpaRepository<AccidentIntakeEntity, Long>`
Create `AccidentFileRepository` interface extending
`JpaRepository<AccidentFileEntity, Long>`
Add custom query method `findByAccidentIntakeId(Long accidentIntakeId)` to
AccidentFileRepository

Update AccidentFileEntity to convert `accidentIntakeId` field from @Column to
@ManyToOne relationship with AccidentIntakeEntity
Use @JoinColumn(name = "accident_intake_id") for proper foreign key mapping
Set fetch type to LAZY
===============================================================================

Task: 2

Implement the service layer for accident intake and file upload business logic.

Create `AccidentIntakeService` with @Service annotation
Inject AccidentIntakeRepository via constructor
Implement @Transactional `createAccidentIntake()` method that accepts intake
details and saves the entity
Set initial status from InsuranceClaimStatus enum
Return created entity with generated ID

Create `AccidentFileService` with @Service annotation
Inject AccidentFileRepository and AccidentIntakeRepository via constructor
Implement @Transactional `uploadAccidentFile()` method that validates intake
exists, converts file content to TEXT, creates AccidentFileEntity with
relationship to AccidentIntakeEntity, and saves the file
Add validation for file size limits and intake existence
Return created file entity with metadata
===============================================================================

Task: 3

Implement the REST API layer with DTOs for accident intake and file upload.

Create DTOs in the dto package:
- `AccidentIntakeCreateRequest` with fields for accident details and validation
annotations (@NotNull, @NotBlank, @Size, @Pattern)
- `AccidentIntakeResponse` with fields matching AccidentIntakeEntity
- `AccidentFileUploadRequest` with fields for intake ID, file name, and file
content with validation
- `AccidentFileResponse` with file metadata fields

Create `AccidentIntakeController` with @RestController and
@RequestMapping("/api/accidents/intake")
Inject AccidentIntakeService via constructor
Implement POST endpoint `createAccidentIntake()` with @Valid request body that
calls service and returns ApiResponse.success() with DTO
Add @Validated annotation for validation

Create `AccidentFileController` with @RestController and
@RequestMapping("/api/accidents/files")
Inject AccidentFileService via constructor
Implement POST endpoint `uploadFile()` with @Valid request body that validates
intake, processes file, and returns ApiResponse.success() with file metadata
===============================================================================

Task: 4

Implement comprehensive error handling infrastructure for accident features.

Update ErrorCode enum to add accident-specific error codes with fields for code,
message, and HTTP status:
- ACCIDENT_INTAKE_NOT_FOUND (404)
- INVALID_ACCIDENT_DATA (400)
- FILE_UPLOAD_FAILED (500)
- FILE_TOO_LARGE (400)
- INVALID_FILE_FORMAT (400)
Provide getter methods

Update GlobalExceptionHandler with @RestControllerAdvice
Add @ExceptionHandler for MethodArgumentNotValidException to handle validation
errors and return ApiResponse.error() with 400 status
Add @ExceptionHandler for CustomException to handle business logic exceptions
and return ApiResponse.error() with appropriate status
Add @ExceptionHandler for Exception as catch-all returning 500 status

Update CustomException to accept ErrorCode parameter
Create AccidentNotFoundException extending CustomException
Create FileUploadException for file processing errors
Throw these exceptions in service layer when business rules are violated

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

💬 Have feedback or questions? Drop into our discord or schedule a call!