내배캠 4주 3일차

오늘 겪은 에러 사항

스프링부트에 스웨거를 연결하려고 할 때 에러가 났다.

의존성을 연결해서 스웨거를 띄워야하는데 강의랑 다르게 jdk나 Spring Boot 버전이 달라서 안되는 거 같아서 스웨거 버전을 바꾸면서 시도 했지만 페이지를 찾을 수 없는 에러가 계속 나왔다.

그래서 계속 버전을 바꾸고 Jdk 버전과 부트 버전을 바꿧지만 해결이 안됐다.

확인해 보니 의존성을 Gradle에서 바꾸고 바로 실행을 눌러서 변경사항이 저장이 안됐던 것이다.

지금껏 의존성을 변경을 해본적이 없어서 저장하고 실행만 하면 될 줄 알았는데 변경사항을 업데이트 해줘야 했던 것을 이번에 처음 알았다.

따라서 앞으로 의존성에 수정이 생길 경우 업데이트를 하겠다고 생각했다. --> 이것때문에 4시간이 사라졌다!

 

 

-------------------

 

오늘은 스프링에 대해 좀 더 배웠다.

아래는 공부하면서 정리한 것

일단 정리는 했는데 잘 모르겠다. 좀 더 이것저것 하면서 깨달으면 될 거 같다.

DDD(Domain Driven Design)에 기반한 기획하기
DDD는 실제 우리가 해결하려는 분야(Domain)의 핵심 문제와 비즈니스 요구사항을 이해하고
이를 소프트웨어 모델에 명확히 반영하는 것을 최우선으로 한 소프트웨어 개발 방법론이다.

DDD의 과정
도메인 주도 설계(DDD)는 전략적 설계와 전술적 설계 2가지로 나뉜다.
    전략적 설계 (strategic Design) : 개념에 대해 정의하고 설계하는데 집중한다.
    도메인을 서로 다른 영역으로 나누고, 각 영역에서 일관된 용어와 모델을 사용하여
    각 영역과 관련해 팀원과 소통하고, 각 영역을 독립적으로 발전하고, 유지보수 하기
    쉽게 만든다. --> 쉽게말해 팀원끼리 소통해서 요구사항을 명확히 정의한다.

    전술적 설계 (Tactical Design) : 각 영역 도메인 모델을 만들고 구현하는 방법에
    중점을 둔다. --> 애플리케이션을 개발하기 위한 구체적인 설계 과정이다.


전략적 설계 Strategic Design
용어 정리
    Ubiquitous Language : 공통된 언어(단어)를 통해 개발자와 도메인 전문가를 포함한
    팀원들 간에 일관된 용어를 사용하자는 개념 -- > 모델링에도 사용되고 코드와 문서에 반영

    Actor : 도메인에 속해 있는 사용자

    Domain Event : 도메인에서 발생하는 사건들이다. 주로 과거 시제로 기록한다.

    Command : Domain Event를 유발시키는 명령이다. 주로 API와 대응된다.

    Policy : 도메인 내의 규칙으로 Domain Event 뒤에 따라오는 하나의 비즈니스 로직이다.
    Policy에 의해 다른 Event가 Trigger 될 수 있다.

    External System : 이메일 전송 시스템, 결제 시스템과 같은 외부 시스템이다.
    외부 시스템에 의해 Event가 Trigger 되기도 한다.

    Hospot : 의문 혹은 질문, 미결정 사항이다.

    Aggregate (합계) : 비즈니스 로직 수행을 위한 데이터 객체의 집합이라고 할 수 있다.
    설계 경험이 적으면 Aggregate를 나누고, 정의하기가 어렵다.
    Aggregate를 정의함으로써, 모델간의 경계를 잘 정의할 수 있고 코드의 일관성을 유지할 수 있다.

    Bounded Context : Actor, Domain Event, Command를 고려한 하나의 집합이다.
    Bounded Context는 복잡한 비즈니스 도메인에게서 이를 구분하고 관리하기 위해
    사용되며 각 컨텍스트 별로 담당하는 조직이 나뉘기도 한다.
    또한 Architecture로 분리되기도 한다.

Design 과정 - Event Storming
1. 각 요소 별로 다른 색의 영역을 설정한다. --> 요소는 Actor, Domain Event, Hotspot, Command, External System, Policy, Aggregate
2. Actor를 정의한다.
3. Domain Event를 모두 나열한다.
    - Event의 순서를 고려하여 나열하면 좋다.
    - Event를 정의하는 중간에 필요할 시 Policy와 Hotspot을 정의한다.
4. Event 앞에 Command를 붙인다.
5. Event 뒤에 External System이 필요할 시 표기한다.
6. Command 앞에 Actor를 설정한다.
7. Event들을 그룹핑하여 Domain Model 및 Aggregate를 정의한다.
8. 필요할 시 Bounded Context를 정의한다.
9. Model의 Data(Model이 담고 있는 정보)에 대해 정의한다.


REST (REpresentational State Transfer)
이름처럼 상태의 전이를 표현하기 위한 HTTP 상의 아키텍쳐 스타일이다.
State는 Resource의 State를 표현하며 Resource는 파일, 문서, 데이터 등을 모두 포함한다.
프로그래머는 데이터를 응답해주는 역할을 하고, 이 데이터는 프로그래머가 정의한 Domain Model에 대한 데이터이기 때문에
Resource가 Domain Model을 칭한다고 봐도 된다.

Representation(표현)이 핵심인데 HTTP를 사용하기 때문에 이 프로토콜을 사용해 표현한다.

    URI(Resource) - URI를 통해 Resource 이름을 표현한다. --> /models
    Method(Verb) - HTTP의 Method를 사용해 상태를 변경하는 행위를 표현한다.
    HTTP Method는 GET, POST, PUT, PATCH, DELETE, OPTIONS로 구성된다
        - GET : Read 요청이다. Resource의 정보를 획득하기 위해 사용한다.
        - POST : Create 요청이다. 새로운 Resource를 생성하기 위해 사용한다.
        - PUT : Update 요청이다. Resource에 대한 정보를 수정하기 위해 사용한다.
            수정된 정보를 포함한 모든 Resource의 정보를 포함해서 요청한다.
        - PATCH : Update 요청이다. Resource에 대한 정보를 수정하기 위해 사용한다.
            수정된 정보만을 요청한다.
        -DELETE : Delete 요청이다. Resource를 삭제하기 위해 사용된다.
        OPTIONS : 서버와 클라이언트 사이의 통신 옵션을 확인하기 위해 사용한다.
            REST에서 표현을 위해 사용하진 않고 HTTP에서 보안 및 효율성을 위해 자동적으로 생성되는 요청이다.

    Json, XML 등 (Representation Of Resource) - Resource의 상태를 표현하는 방법이다.


REST Style API 디자인 가이드

    - URI 즉 Resource의 이름은 명사, 소문자, 복수형을 권장한다. --> /posts

    - / 를 통해 Resource 관의 계층 관계를 표현한다. /는 has를 의미한다라고 생각
        예를 들어 특정 포스트에 달린 댓글들을 URI로 표현하면 /posts/{id}/comments가 된다

    - URI 마지막에 /를 포함하지 않는다. --> /posts/ (X)

    - 밑줄(_)은 사용하지 않고 가동석을 높이려면 하이픈(-)를 사용한다.

    - 특정 Resource 하나를 가져올 때에는 URI에 해당 Resource의 Identifier를 포함하여 표시한다.
        --> /posts/{id}

    - Resource 목록의 페이징, 필터링, 정렬, 검색을 통해 정보를 가져올 시 Path Variable을 활용한다.
        --> /posts?page=12 , /posts?order=latest

    - 적절한 Status Code를 응답한다.
        상태 분류
        - 1XX ( Informational - 정보 제공)
            임시 응답이다. 요청이 수신되었으며 프로세스가 계속 진행 중임을 알림
        - 2XX (Successful - 성공)
            요청이 성공적으로 처리되었음을 나타낸다.
        - 3XX (Redirection - 리다이렉션)
            클라이언트가 요청한 리소스의 위치가 변경되었음을 나타낸다.
        - 4XX (Client Error - 클라이언트 오류)
            클라이언트의 요청에 오류가 있음을 나타낸다.
        - 5XX (Server Error - 서버 오류)
            서버에서 요청을 처리 중에 문제가 발생한 경우이다.
            서버 부하, DB관련 오류 등 클라이언트에 의한
            오류가 아닌 서버의 장애로 발생할 때 사용된다.

        자주 쓰는 오류 코드

        - 200 : OK
        - 201 : Created, 리소스가 정상적으로 생성됨
        - 204 : No Content, 리소스가 삭제됨
        - 400 : Invalid Request, 요청이 잘못됨
        - 401 : Unauthorized, 클라이언트가 인증되지 않았거나, 인증정보가 부족함
        - 403 : Forbidden, 서버가 요청을 이해했으나 권한이 없음
        - 404 : Not Found, 리소스를 찾을 수 없음
        - 500 : Internal Server Error, 서버의 내부 에러
        - 501 : Not Implemented, 요청한 URI의 메소드에 대해 준비가 안됨
        - 502 : Bad Gateway, 게이트 웨이 역할을 하는 서버가 뒷단의 서버로부터 잘못된 응답을 받음


        ex) 글과 댓글의 생성, 조회, 수정, 삭제
        글 목록 조회 : GET -> /posts
        단일 글 조회 : GET -> /posts/{id}
        글 생성 : POST -> /posts
        글 수정 : PUT -> /posts/{id}
        글 삭제 : DELETE -> /posts/{id}
        특정 글의 댓글 목록 조회 : GET -> /posts/{id}/comments
        특정 글에 댓글 추가 : POST /posts/{id}/comments
        특정 글의 댓글 수정 : PUT -> /posts/{id}/comments/{id}
        특정 글의 댓글 삭제 : DELETE -> /posts/{id}/comments/{id}

REST와 RESTful

restful하다는 REST를 아주아주 잘 지키는 것이다.
위에서 나온 REST는 REST의 모든 것이 담겨 있지 않다.
아래와 같은 단계가 있다.

    level 0 : The Swamp of POX
        소수의 URI를 갖고 있고 일반적으로 POST만을 사용하는 스타일

    level 1 : Resources
        위에서 설명한 REST와 유사하게 URI를 통해 Resource를 표현한다.
        하지만 Verb (HTTP Method)를 POST만 주로 이용한다

    level 2 : HTTP Verbs
         위에서 설명한 REST이다. Resource를 URI로 사용하면서
         HTTP Method를 통해 행위에 대해서도 표현한다.

    level 3 : Hypermedia Controls
        level 2 에 더해서 HATEOS(Hypertext As The Engine Of Application State)를 잘 지킨 단계다
        클라이언트에게 응답을 할 시 다음 단계로 할 수 있는 작업에 대해 알려주기도 한다.
        Resource에 대한 데이터만 응답하는 것이 아닌 클라이언트의 다음 작업을 위한 URL도 함께 알려준다.

    일반적으로 Level 3까지 준수할 때 RESTful하다고 정의한다.
    level 3를 지킬 때 클라이언트는 각 요청을 위한 URI를 몰라도 되고
    응답 만으로 다음 행위를 어떻게 할 지 판단할 수 있다.
    하지만 이를 위한 서버측, 그리고 클라이언트 측의 개발 기간은 늘어난다.
    요새는 여러 편한 Tool이 등장해서 편리해졌다.
    따라서 빠른 개발 생산성을 위해 일반적으로 level 2 까지만 준수한다.