Tactical Design & REST API

✔오늘 배운 중요한 🔑 point

• 상태의 전이는 클라이언트가 서버에 요청을 보내면서 리소스의 상태가 전이되거나 변경하는 과정을 의미한다. 따라서 단순히 데이터를 조회하는 GET 요청이나 데이터를 전송하는 POST 요청은 상태의 전이와 직접적인 관련이 없고 주로 PUT,PATCH,DELETE등의 요청은 리소스의 상태가 변경되기 때문에 상태의 전이와 직접적인 관련이 있다고 할 수 있다.
• REST API를 사용하는 이유는 HTTP 위에서 API를 통한 통신을 하기때문에 이 HTTP를 최대한 활용하고자 함이고 API만 보고 이 API가 어떤 Command를 수행하는지 쉽게 알기위해서 일반적으로 많이 선택된다

 

 

🎯 오늘 배운 내용

 

기획 및 설계

 

DDD (Domain Driven Design)

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

 

 

DDD의 과정

 

전략적 설계 ( Strategic Design )

개념에 대해 정의하고 설계하는데 중점.

도메인을 서로 다른 영역으로 나누고, 각 영역(Context)에서 일관된 용어와 모델을 사용하여 각 영역과 관련해 팀원과 소통을하고, 각 영역을 독립적으로 발전하고, 유지보수 하기 쉽게 만듬

즉, 소프트웨어를 설계하기전 요구사항에 대하여 명확이 정의하고, 개념적인 설계를 하는 과정.

 

전술적 설계 ( Tactical Design )

각 영역(Context, Bounded Context) 도메인 모델을 만들고구현하는 방법에 중점

즉, 애플리케이션을 개발하기 위한 구체적인 설계 과정

 

 

전략적 설계 ( Strategic Design )에 대해 더 알아보자!

 

전략적 설계의 용어

• Ubiquitous Language: 공통된 언어(단어)를 통해 개발자와 도메인 전문가를 포함한 팀원들 간에 일관된 용어를 사용하자는 개념. 이 언어는 모델링에 사용되고, 코드와 문서에도 반영
• Actor: 도메인에 속해있는 사용자
• Domain Event: 도메인에서 발생하는 사건들. 주로 과거 시제로 기록. (e.g. 로그인에 성공함, 상품이 배송됨)
• Command: Domain Event를 유발시키는 명령. 주로 API와 대응.
• Policy: 도메인 내의 규칙으로, Domain Event뒤에 따라오는 하나의 비즈니스 로직. Policy에 의해 다른 Event가 Trigger될 수 있음. (e.g. 매월 카드 결제일이 되면 계좌에서 결제대금이 빠져나간다)
• External System: 이메일 전송 시스템, 결제 시스템과 같은 외부 시스템. 외부 시스템에 의해 Event가 트리거 되기도 함.
• Hotspot: 의문 혹은 질문, 미결정 사항.
• Aggregate: 비즈니스 로직 수행을 위한 데이터 객체의 집합. (e.g. 주문이라는 agreegate는 배송정보, 결제정보와 같은 Domain Model(Entity)로 이루어져 있음.) 설계를 많이 경험해보지 않으면, Aggregate를 나누고, 정의하기가 참 어렵긴 하지만, Aggregate를 정의함으로써, 모델간의 경계를 잘 정의 할 수 있고, 코드의 일관성을 유지할 수 있음. 도메인이 복잡할 때 더욱 힘이 발휘함.
• Bounded Context: Actor, Domain Event, Command를 고려한 하나의 집합. (e.g. 쇼핑몰을 예로 들면, 회원 가입, 정보 수정등을 담당하는 회원 Context, 상품의 주문 및 결제를 담당하는 상품 Context, 배송을 담당하는 배송 Context가 있음.) Bounded Context는 복잡한 비즈니스 도메인에서 이를 구분하고, 관리하기 위해 사용되며 각 컨텍스트 별로 담당하는 조직이 나뉘기도 함. 또한, Architecture로 분리되기도 함.

 

디자인 과정- Event Storming

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

 

1. 요소 별 다른 색의 포스트잇 설정

 

 

2. Actor 정의 ( 사용자 정의 )

 

 

3. Domain Event 나열 ( 이 수강신청 Application에서 생길 수 있는 모든 Event를 나열 )

 

 

4. Command 설정 ( Event를 유발시키는 명령, 추후 API가 됨)

 

5. External System 표시 (필요하지 않으니 pass)

 

6. Actor 표기 ( Command를 수행하는 Actor가 student인지 tutor인지 구분 )

 

 

 

7.  Event Grouping 및 Model, Aggregate 정의

↓

 

 

8. BoundedContext 정의 ( 여기서는 별도로 나누지 않음)

 

9. Data 정의  ( 각각의 Model이 담고 있는 정보에 대해 정의 ) 

 

 

 

 

REST API

 

 

REST

상태의 전이를( State Transfer) 표현하기 위한 HTTP 상의 아키텍쳐 스타일

※ 상태의 전이: 클라이언트가 서버에 요청을 보내면서 발생하는 과정.  쉽게 말해 클라이언트가 서버에 요청하고 서버가 응답하는 과정이 상태의 전이라고 할 수 있음

★★★ 하지만 데이터를 단순히 조회하는 GET요청이나 데이터를 전송하는 POST요청의 경우에는 요청을 통해 상태가 변하지는 않으므로 상태의 전이가 아니다. 

 

REST API를 사용하는 이유?

API를 설계하는 방법은 여러가지가 있지만 우리는 HTTP위에서 통신을 하니, HTTP를 최대한 활용하는것이 좋고 API만을 보고도 API가 어떤 Command를 수행하는 API인지 알면 좋기때문에 REST API를 일반적으로 많이 사용한다

 

HTTP 프로토콜 표현을 위한 구성 요소

• URI(Resource) - 먼저 URI 를 통해 Reousrce 이름을 표현. e.g)  /models
• Method(Verb) - HTTP의 Method를 사용해 상태를 변경하는 행위(Verb)를 표현. 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의 상태를 표현하는 방법. 어떤 형태의 데이터 구조를 사용해도 무방하지만, 우리는 JSON을 사용할 예정

 

 

RESTful API란?

REST의 규칙을 아주 잘 지킨 API, 일반적으로 성숙도 모델 LV3까지 준수를 할때 RESTful하다고 한다

 

• Level 0: The Swamp of POX
  • 소수의 URI를 갖고 있고, 일반적으로 POST만을 사용하는 스타일
• Level 1: Resources
  • URI를 통해 Resource를 표현. 하지만, Verb (HTTP Method)를 POST만 주로 사용.
• Level 2: HTTP Verbs ★(일반적으로 Level 2까지 준수)
  • Resource를 URI로 사용하면서, HTTP Method를 통해 행위(Verb)에 대해서도 표현
• Level 3: Hypermedia Controls (RESTful API)
  • Level 2에 더하여 HATEOS(Hypertext As The Engine Of Application State) 를 잘 지킨 단계. 클라이언트에게 응답을 할 시 다음 단계로 할 수 있는 작업에 대해 알려주기도 함. 즉, Resource에 대한 데이터만 응답하는 것이 아니라, 클라이언트의 다음 작업을 위한 URL 도 함께 알려준다. 예를들어, 댓글을 조회할 시 댓글에 좋아요를 달거나, 대댓글을 달 수 있는 API URL이 뭔지를 함께 알려주는 것입니다.

 

 

🤔 어떻게 활용할까?

REST API는 웹 애플리케이션에서 사용되기때문에 백엔드 개발자로서 REST API를 통해 서버에서 데이터를 요청하고 응답을 받아오는 과정을 잘 이해하고 있어야 할 것이다.

📓 오늘의 한줄

"There is no friend as loyal as a book."

- Ernest Hemingway -