부트캠프 16일차 후기

오늘로 4주차에 돌입되는 부트캠프, 월요일인지로 몸이 많이 나른하다. 그래서인지 출석체크를 늦게 하는 실수를 저질러버렸다. 내가 봐도 한심한 실수다.

 

오늘도 CodeKata 2문제를 풀었다. 그렇게 LV3을 마치고 LV4에 돌입하였다. 이제 슬슬 프로그래머스 자체 IDE로 코딩하는 것도 한계가 느껴진다. 물론 Intellij로 옮겨서 코딩을 한 적 있었지만 기본적으로 자체 IDE에서 코딩했고, 난이도도 올라가버리니까 되려 안 옮긴것 보다 시간을 더 많이 잡아먹었는 것 같다. 2문제밖에 못 푼 것도 Intellij에서 코딩했으면 시간이 단축되었을 버그들이 원인이 되었다. 어쨌든 이제 LV4로 올라도 왔으니 이제부턴 Intellij를 주 IDE로 써야겠다.

 

오늘부터 Spring에 들어간다. 팀을 다시 짜긴 했지만 같이 모여서 할 게 없어서, 모르는 것이 있으면 물어보라는 말만 하고, 각자 공부하는 방향으로 가닥으로 잡았다. 그렇게 오늘은 Spring 입문 강좌를 들었고, 기억에 두면 좋을 만한 것을 남기려고 한다.

 

먼저 Framework와 Library의 차이점에 대해 배웠다.  framework는 Application을 호출하는 Caller의 역할이고, Library는 Application이 호출하는 Callee의 역할이다. 이 둘의 차이점은 자주 헷갈리기에 다시 한번 개념정리를 해 두는 것이 좋겠다.

 

그리고 Package, Module, Library의 개념을 알게 되었다. Package, Module, Library 순으로 갈 수록 사이즈가 커진다는 사실 정도로 기억해두자.

 

이후 웹 생태계의 변화에 대해 알게 되었는데, 여기서 짚고 넘어가고 싶은 것은 3세대와 4세대이다.

3세대는 JavaScript를 활용해 클라이언트에서 렌더링하는 방식(CSR)이고, 4세대는 서버에서 렌더링하는 방식이다.(SSR)

3세대는 첫 페이지 로딩이 느리지만 그 이후가 빠르고 4세대는 첫 페이지는 빠르지만, 변경사항 등의 페이지를 불러오는 시간이 느리다. 그리고 3세대는 검색이 잘 안된다는 단점이 있다. 요즈음엔 3세대와 4세대의 장점을 활용할 수 있는 Next.js와 같은 프레임워크가 있다는 사실이 있다는 사실도 짚어두자.

내가 Spring을 배우가 가장 헷갈렸던 기초는 DispatcherServlet이다. DispatcherServlet은 Client로부터 요청을 받으면 HandlerMapping을 통해 Controller를 검색하고, HandlerAdapter로 처리를 요청한다. 그렇게 요청된 Request는 Controller, Service, Repository를 거쳐 처리되고, 다시 Dispatcher Servlet을 통해 Client로 Response한다. HandlerMapping과 HandlerAdapter는 가끔씩 마주하게 되면 혼란스럽기에 이렇게 글을 적으며 머릿속을 정리하자.

 

 

위의 것들은 어느정도 아는 지식 내용에 약간의 살을 붙는 형식으로 정리하는 것이지만 한편으론, 새롭게 배운 내용도 있다. DDD에 기반한 기획은 이번에 새롭게 배운 내용이다.

 

여기서 DDD는 개념을 정의하고 설계하는 데에 중점을 두는 "전략적 설계"방식과 구현 방법에 중점을 두는 "전술적 설계" 방식이 있는데, 이 강의에서는 전략적 설계 방식에 초점을 두고 설명을 하였다.

 

전략적 설계에서 사용되는 용어가 존재하는데, 간단히 설명하자면 다음과 같다.

Ubiquitous Langauge: 팀원끼리 일관된 용어를 사용하자는 개념이다.

Actor: 사용자

Domain Event: 도메인 내에서의 사건, 과거형으로 기록

Command: Domain Event를 발생시키는 명령 -> API에 대응

Policy: 규칙, Domain Event 뒤에 따라오는 비즈니스 로직.

External System: 외부 시스템

HotSpot: 미결정 사항

Aggregate: 비즈니스 로직 수행을 위한 데이터 객체의 집합.(설계하기 어려움)

Bounded Context: Actor, Domain Event, Command를 고려한 하나의 집합

 

그리고 각 단계는 이러하다.

 

1. Actor 정의

2. Domain Event 모두 나열(순서 고려가 Best, 필요할 시 HotSpot, Policy 정의)

3. Event 앞에 Command 첨부 (필요 시 External System 표기)

4. Command 에 Actor 설정

5. Event 그루핑해서 Domain Model 및 Aggregate 정의 (필요시 Bounded Context 정의)

6. Model의 Data에 대해 정의.

 

대강 이러한 단계를 거쳐 프로그램을 기획 및 설계할 수 있겠다. 현재 나는 개인 프로젝트 준비를 고려중인데, 이 정보는 앞으로 큰 도움이 될 것 같다.

 

마지막으로 REST-API에 대해 다시 배우게 되었는데, 여기서 배운 것은 두 가지이다. 첫 번째는 PATCH 메소드이다. 그 동안 나는 Resource를 Update하는 요청을 PUT만 존재하는 줄 알았는데, PATCH 메소드 또한 존재한다는 것을 이번에 처음 알게되었다. PUT과의 차이점은 PUT은 모든 정보를 요청하지만, PATCH는 수정되는 정보만 요청한다는 점이다. 두번째는 "/"를 통한 계층관계는 has를 의미한다는 것이다. 이전에 REST-API를 조금 건들인 적이 있었는데, 나는 추가적인 정보를 줄 때 "/"를 사용해서 만든 적이 있었다. 그렇지만 그것이 좋은 선택이 아니였다는 이야기이다. 앞으로도 이렇게 잘못된 지식을 고쳐나가도록 해보자.

 

이대로 끝나긴 아쉬우니 강의에서 써볼만한 함수도 조금 건졌다. 첫 번째는 any이다. list에서 특정 조건을 만족하는 원소가 하나라도 존재한다면 true를 반환하는 함수이다. 덤으로 모든 원소가 조건을 만족하는 all과 그 반대인 none도 있다.

 

 

first는 list에서 해당 조건을 만족하는 첫번째 원소를 반환하는 함수이다. 그 반대로 마지막 원소를 반환하는 last가 있다. 다만 이 두 함수는 빈 list나 조건을 만족하는 값이 없으면 Error를 일으키기에 그러한 조건이면 null을 반환하는 firstOrNull이다 lastOrNull을 사용하는 것이 더 안정적으로 느껴진다.

 

일단 오늘은 여기까지 하고 내일은 되도록 Spring 숙련강의를 마칠 예정이다. 설령 못 마치더라도 수요일안에 꼭 마무리짓고 숙제에 돌입하자.