03. 3계층 스프링 부트 애플리케이션

- 다층 아키텍처(multitier architecture) : 애플리케이션을 여러 계층으로 나눈 아키텍처

  - 클라이언트 계층 : 사용자 인터페이스를 제공하는 계층. 보통 프런트엔드라고 부름

  - 애플리케이션 계층 : 비즈니스 로직, 상호작용을 위한 인터페이스, 데이터를 저장하는 인터페이스를 포함하는 계층. 보통 백엔드라고 부름

    > 비즈니스 레이어 : 도메인과 비즈니스 명세를 모델링한 클래스가 있음. 애플리케이션의 두뇌 역할

                                  보통 개체와 비즈니스 로직을 제공하는 서비스의 조합으로 이루어짐

                                  해당 레이어를 도메인(개체)와 애플리케이션(서비스)로 나누기도 한다

    > 프레젠테이션 레이어 : 컨트롤러 클래스(웹 클라이언트에 기능을 제공)

    > 데이터 레이어 : 개체들을 데이터 스토리지나 데이터 베이스에 보관

                               보통 데이터 액세스 객체(DAO : Data Access Object) 또는 저장소 클래스를 포함한다

                               DAO는 데이터베이스 모델을 다루고, 저장소 클래스는 도메인을 데이터베이스 레이어로 변환하는 클래스이다

  - 데이터 저장 계층 : 애플리케이션의 데이터를 보관하는 계층. 데이터베이스, 파일 시스템 등

>> 이 소프트웨어  아키텍처는 레이어를 분리하고 결합도를 낮춘다

     - 이점 : 도메인과 솔루션이 분리되어 있다. 인터페이스나 데이터베이스 명세와 섞여 있지 않다

                 프레젠테이션과 데이터 레이어는 다른 레이어로 교체할 수 있다

                 각 레이어의 역할이 명확히 구분된다

                  > 비즈니스 로직을 처리하는 클래스, REST API를 구현하는 클래스, 객체를 데이터베이스에 저장하는 클래스로 나뉜다

 

+) @SpringBootTest를 남용하지 마라

- SpringRunner는 애플리케이션 컨텍스트를 초기화하고 필요한 객체를 주입함

- 컨텍스트는 캐시로 재사용할 수 있어서 테스트당 한번만 로딩됨

- 단순히 클래스 하나의 기능을 테스트 하기 위해서라면 종속성을 주입하거나 애플리케이션 컨텍스트가 필요하지 않다

- 컨텍스트를 재사용한다고 하더라도 @SpringBootTest를 사용하면 자원과 시간을 낭비하게 되고, 트랜잭션 롤백과 부작용이 발생하지 않도록 스프링 컨텍스트를 정리해야 한다

- 여러 클래스 간의 상호작용을 확인하는 통합 테스트에서 @SpringBootTest를 사용

 

* 도메인 설계

- 비즈니스 로직에서 사용하는 객체

  > Multiplication : 곱셈의 인수와 연산을 포함

  > User : 곱셈 문제를 푸는 사용자를 식별

  > MultiplicationResultAttempt : Multiplication과 User의 참조를 포함하고 사용자가 제출한 값과 채점 결과를 포함

 

+) 불변성(Immutability) : 다중 스레드 환경에서 일어날 수 있는 여러 문제에서 안전하게 만들어준다

+) 롬복(Lombok) : 컴파일러 동작 전에 애너테이션을 기반으로 코드를 생성한다

                             코드의 중복과 불필요한 부분을 제거해 간결하게 만든다

     > @RequiredArgsConstructor : 모든 상수 필드를 갖는 생성자를 만든다

     > @Getter : 모든 필드의 getter를 만든다

     > @ToString() : 해당 클래스의 toString() 메서드를 읽기 쉽게 만든다

     > @EqualsAndHashCode() : equals()와 hasCode() 메서드를 만든다

 

* 비즈니스 레이어

- 필요한 로직

  > 제출한 답안의 정답 여부 확인

  > 적당히 어려운 곱셈 만들어내기

 

* 프레젠테이션 레이어(REST API)

- REST : HTTP를 기반으로 하는 기초적인 인터페이스로 간단하게 사용할 수 있음

              웹서비스를 만드는 잘 알려진 표준

   > REST가 꼭 필요한 것은 아니지만 만드는 이유

      : 스프링 mvc를 이용해 html 같은 뷰 레이어 구현체로 렌더링 할 수 있지만 코드 기반에 뷰를 설계하면 수정하기 어려워짐

        REST를 사용하면 UI 필요 없이 HTTP만을 사용해 인터페이스를 제공할 수 있음

        하나의 API로 여러 가지 백엔드 서비스에 기능을 제공할 수 있음

- 제공해야하는 인터페이스

   > 적당히 어렵고, 무작위로 생성된 곱셈 문제를 제공하는 API

   > 주어진 곱셈을 계산한 결가와 누가 풀었는지 알 수 있도록 사용자의 닉네임을 제출하는 API

     => GET /multiplications/random : 무작위로 생성한 곱셈을 반환

     => POST /results : 결과를 전송하는 엔드포인트

     => GET /result?user=[user_alias] : 특정 사용자의 계산 결과를 검색

- 모든 것을 하나의 컨트롤러에 담지 말고 비즈니스 개체와 연관된 인터페이스에 분리해서 담는 것이 좋다

- TEST

   > @WebMvcTest() : 스프링의 웹 애플리케이션 컨텍스트를 초기화 한다

                                    @SpringBootTest처럼 모든 설정을 불러오는 것이 아니라 MVC 레이어(컨트롤러)와 관련된 설정만 불러온다

                                    MockMvc 빈도 불러온다

   > @MockBean : 목 객체는 given() 메서드에서 지정한대로 값을 반환한다

   > JacksonTester 객체를 사용해 JSON의 내용을 쉽게 확인할 수 있다

+) @WebMvcTestdhk @SpringBootTest의 차이

    - @WebMvcTest는 컨트롤러를 테스트하는 애너테이션

       HTTP 요청과 응답은 목을 이용해 가짜로 이뤄지고 실제 연결은 생성되지 않는다

    - @SpringBootTest는 웹 애플리케이션 컨텍스트와 설정을 모두 불러와 실제 웹 서버에 연결을 시도한다

       클라이언트부터 상호작용을 확인하는 통합 테스트에서 사용하는 것이 좋다(간단한 컨트롤러 단위 테스트에서 사용하지 않는 것이 좋음)

       MockMvc가 아니라 RestTemplate(또는 TestRestTemplate) 사용

- @RestController : 해당 컨트롤러와 @RequestMapping(또는 @GetMapping)이 붙은 메서드가 응답 내용 자체를 반환함

                                @Controller + @ResponseBody

   @RequestMapping : 클래스에 붙이면 클래스 내 모든 메서드에 최상위 경로를 지정

   @GetMapping : @RequestMapping(method=RquestMethod.GET)을 줄여 쓴 것

 

 

+ 더 찾아볼 것

- @MockBean과 @Mock의 차이

- JacksonTester

- @AutoWired를 변수에 하는 것 vs 생성자에 하는 것