레벨2 인터뷰

DTO vs Domain vs Entity

Dto는 Data Carrier로 (CSR 등) 외부 API 혹은 모델에 담을 때 (SSR) 사용한다

특히 Presentation Layer는 Domain이나 Entity가 아니라 꼭 dto를 반환하는 것이 좋다

왜냐하면 API 스펙이 바뀌게 되면 Domain과 Entity 또한 바뀌게 되는 경우도 있고

반대로 domain 혹은 entity가 바뀌게 되면 API 스펙이 바뀌게 되기 때문이다.

domain과 entity의 차이는 db접근 계층에 누가 더 가깝냐에 따라 나눌 수 있다

entity가 좀 더 직접적으로 가까운 계층이고 domain은 그와 좀 더 멀리 있는 역할이라고 볼 수 있다

그러나 entity domain 둘 중 하나가 다른 한 쪽의 뜻을 대변하고 있다고 볼 수도 있을 것 같다

예를 들어 Spring-Data-JPA를 사용하고 있으면 Entity 자체가 Domain 역할도 하고 있는데

객체가 참조값이 아닌 객체를 알고 있을 수 있는 등 객체다운 행동이 가능해지기 때문에 Domain이라고 볼 수 있을 것 같다.

Dao vs Repository

• dao는 entity를 알고 있는 DB와 가장 근접한 Layer

• repository는 dao를 한 번 더 추상화한 Domain을 알고 있는 Layer

Spring-Data-JPA 을 사용하면

dao를 추상화한 repository를 사용하게 된다

따라서 기존에는 Entity와 Domain을 나누는 방식으로 진행했다면

현재는 ORM 기술이 그 간격을 좁혀줄 수 있으므로 굳이 나눌 필요가 없다

Spring (예외) 처리 과정

크게는

톰캣(1) - 프론트 컨트롤러(2) - 사용자 정의 컨트롤러(3)라고 볼 수 있을 것 같다

이때 부가적으로 용어 정리를 다시 한 번 하면

톰캣(1): WAS, 서블릿 컨테이너, 요청 쓰레드를 기본값으로 200개 지니고 있음

(2): Dispatcher Servlet

• 사용자가 정의한 컨트롤러를 찾아주는 역할을 한다.

• 공통처리를 담당한다

  • View Resloving - 뷰 찾아주기
  • Argument Resolving - 컨트롤러 인자 찾아주기
  • Return Value Resolving - 컨트롤러 리턴값을 JSON으로 해석하여 API 응답

• 순수 Servlet을 이용하면 사용자가 URL 매핑하는 부분을 정의해주어야 한다.

(3): 사용자 정의 컨트롤러

사용자가 직접 정의한 URL을 매핑하는 컨트롤러이다

이곳에서는 외부에서 오는 요청 처리를 담당하고 어떤 데이터(API) /혹은 SSR 화면 /정적 리소스를 호출할 지를 정한다.

WAS(1) - 필터(2) - 프론트 컨트롤러(3) - 핸들러 매핑(4) - 핸들러 어댑터(5) - 인터셉터 핸들러(6)

WAS에서 요청을 받는다. 이때 톰캣8~9를 기준으로 NIO를 사용하는데 내부적으로 소켓 비동기 통신 / 쓰레드를 캐싱한다

(2) 필터를 거친다, 이곳에서 인증/보안 처리를 할 수 있다

(3) 프론트 컨트롤러를 거치는데,

이곳에서 어떤 핸들러를 거칠지 찾아주며 (4) - 정확히는 핸들러 + 핸들러 메서드 (컨트롤러와 그 메서드)

찾아준 핸들러를 알맞은 형식에 맞게 변환해준다 (5)

• RequestMappingHandlerAdapter

핸들러 어댑터(5)를 통해서 Argument Resolver를 통해서 핸들러가 필요로 하는 인자를 찾아준다.

스프링와 예외처리

핸들러에서 예외가 터질 경우

Exception Resolver가 동작한다.

인터셉터에서 예외가 터질 경우

핸들러와 마찬가지다.

핸들러와 인터셉터는 모두 ExecutionChain 이라는 객체에 담겨서 처리가 되는데,

이곳에서 예외 발생시 컨트롤러 어드바이스에서 예외처리가 된다.

사용자 정의 필터에서 예외가 터질 경우

도메인 개발자가 정의한 필터에서 예외가 터진 경우 예외를 잡지 못하며 Default Handler에서 처리되는 예외가 그대로 전송한다.

스프링 예외처리 - rollBackFor

스프링 @Transactional 은 Un-Checked Exception 에 대해서만 커밋/롤백을 해준다 ! Checked Exception에 대해서는 위와 같은 처리를 하지 않는다.

스프링 빈 등록 vs 정적 클래스

• 싱글톤패턴 구현할 핑요 x
• 프로토 타입 등 스코프 상태 설정 가능
• 테스트 용이
• aop 먹일 수 있음

빈 등록해주는 것은 프레임워크의 레벨이기 때문에 싱글톤 패턴 설계할 필요 x 따라서 상태를 갖는 객체의 경우 프로토타입 빈 스코프로 찍어낼수있으며 테스트하기도 좋다 (싱글톤이라는, 메모리 상 상태를 하나만 가져야한다는 제약 x ) 또 aop기능을 이용해서 처리할 수 있다. 기본적으로 aop를 사용하려몀 bean 등록이 되어 있어야 한다 !

ResponseEntityExceptionHandler

• 커스텀 예외 처리를 하면서 스프링에게 예외 처리를 맞길 수 있다

405 등의 처리를 스프링에게 맞기고 싶을 때 내부적으로 30개 메서드로 분기를 타는데 결국 하나의 메서드로 집결한다. 이 하나의 메서드를 상속 받아서 사용하면 된다 !

MockMvc  vs  RestAasured 목 사용 vs 인수테스트 탑다운 vs 바텀업

목 사용의 경우 내부 구현을 미리 상상하면서 구현해야하는 단점이 있다 대신방향을 잃을 가능성은 적다

바텀업 방식은 초보자도 하기에 용이하게 객체 설계를 하며 도메인 지식을 쌓아나갈 수 있다 대신 방향을 잃을 가능성이 있다

테스트에 대한 생각

테스트를 하다보면 테스트 코드 자체 내에서도 여러 중복 코드가 많이 생기기 마련이다

도메인 리포 서비스 컨트롤러(목) 인수

너무 많은 테스트 코드는 새로운 코드나 메서드 구조를 다시 잡을 때 작업 공수가 넘  많아지게 되어 변경을 대처할 때 집중력이 흐려지기 좋다 (개발자도 사람이기에 집중할 수 있는 시간이 한정되어 있다)

따라서 핵심적으로 두어야할 테스트를 2가지 꼽는다면 나라면

클라이언트 입장에서 필요한 인수테스트와 내부적으로 빠른 테스트를 해볼 서비스 테스트를 할 것 같다