통합 테스트

• 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.

• 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트

Spring

Library

• 내 코드가 주체!!

• 외부에 있는 기능을 끌어 옴

Framework

• 이미 동작 할 수 있는 환경

• 내 코드가 수동적

Spring

• IOC

• DI

• AOP

JPA

ORM : Object-Relational Mapping

• 객체 지향 패러다임과 관계형 DB 패러다임의 불일치

• 단순 작업을 줄이고 비지니스 로직에 집중 할 수 있다.

JPA

• 인터페이스 이고 여러 구현체가 있지만 보통 Hibernate를 많이 사용한다.

• 편리하지만 어떤 식으로 쿼리가 만들어지고 실행되는지 명확하게 이해하고 있어야 한다.

Sping Data JPA

• JPA 를 한번 더 추상화한 Spring Data JPA 제공

• QueryDSL과 조합하여 많이 사용한다. (타입체크, 동적 쿼리)

※ @AllArgsConstructor 를 지양하시는 이유

빌더 패턴은 빌더 패턴의 장점이 별도로 있기 때문에 사용하는 것이고, @AllArgsConstructor 를 사용하지 않는 이유는 별개의 이유입니다.

@AllArgsConstructor는 편리하게 모든 필드를 가진 생성자를 만들어 주지만, 필드의 순서가 변경되는 경우 치명적일 수 있습니다.

예를 들어 어떤 객체가 2개의 String 타입을 필드로 가지고 있고, 이에 대한 생성자를 외부에서 사용하고 있다고 가정해 봅시다.

해당 객체의 필드 순서가 실수로 변경되어도 컴파일 에러가 발생하지 않고, 추후 인지하지 못한 치명적인 버그가 발생할 수 있는 여지가 됩니다.

그럼 @RequiredArgsConstructor를 사용해도 final 키워드만 붙었지 마찬가지 아닌가, 싶으실텐데요. 맞습니다. AllArgs~와 동일한 문제를 안고 있지만, 저는 그래도 편의성을 위해 @RequiredArgsConstructor정도는 인지하고 사용하자는 편입니다.

이유는 다음과 같은데요.

• 사용자가 final 키워드를 붙이면서 필수 파라미터에 대한 인지를 하고 필드를 선언한다는 점

• 스프링에서는 객체의 생성자만 만들어두면 스프링에서 알맞은 타입과 이름의 빈을 찾아서 주입해주기 때문에, 필드 순서가 바뀌거나 해도 타입+이름 기반으로 동작하니 @RequiredArgsConstructor 를 사용해도 큰 무리가 없음

  • 다만 스프링의 Bean이 아닌 사용자가 직접 만들고 사용하는 일반 객체라면, 위 문제를 방지하기 위해 @RequiredArgsConstructor 대신 그냥 생성자를 사용해보는 것을 고려해볼 수 있습니다.

※ 패키지 구성

애그리거트(Aggregate) 기준으로 패키지를 나누고 하위에 domain, sub-domain, service, repository 등을 위치시켜 컨텍스트를 나누는 방식으로도 사용할 수 있습니다.

Persistence Layer

• Data Access 의 역할

• 비지니스 가공 로직이 포함되어서는 안된다. Data에 대한 CRUD에만 집중한 레이어

• 데이터를 담당하는 부분으로서 꼼꼼하게 확인을 해둬야하는 부분

Business Layer

• 비지니스 로직을 구현하는 역할

• Persistence Layer와의 상호작용을 통해 비지니스 로직을 전개시킨다

• 트랜잭션을 보장해야 한다.

• 트랜잭션에 대한 이해를 해야 운영에서 문제 없이 돌아 갈 수가 있다.

Presetation Layer

• 외부 세계의 요청을 가장 먼저 받는 계층

• 파라미터에 대한 최소한의 검증을 수행한다.