TIL 20231220

DDD( Domain Driven Design)
실제 우리가 해결하려는 분야(Domain)의 핵심 문제와 비즈니스 요구사항을 이해하고, 이를 소프트웨어 모델에 명확히 반영하는 것을 최우선으로 한 소프트웨어 개발 방법론이다. 이렇기 때문에, DDD에는 요구사항을 명확히 이해하고, 정의하는 부분까지 포함되어 있다.
 
도메인 주도 설계(DDD) 전략적 설계(Strategic Design)와 전술적 설계(Tactical Design)라는 두 가지 주요 과정으로 나뉘는데,
 
전략적 설계(Strategic Design): 개념에 대해 정의하고 설계하는데 중점을 둔다. 도메인을 서로 다른 영역으로 나누고, 각 영역(Context)에서 일관된 용어와 모델을 사용하여 각 영역과 관련해 팀원과 소통을하고, 각 영역을 독립적으로 발전하고, 유지보수 하기 쉽게 만든다. 즉, 소프트웨어를 설계하기전 요구사항에 대하여 명확이 정의하고, 개념적인 설계를 하는 과정이라고 볼 수 있다.

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

---

 
자세히 해 볼 건 전략적 설계라고 한다.
 
Ubiquitous Language: 공통된 언어(단어)를 통해 개발자와 도메인 전문가를 포함한 팀원들 간에 일관된 용어를 사용하고 있는 개념이다. 이 언어는 모델링에 사용되고, 코드와 문서에도 반영된다.

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

Domain Event: 도메인에서 발생하는 사건들이다. 주로 과거 시제로 기록한다. 예시로 들자면, 로그인에 성공함, 상품이 배송됨 등 이런식으로 사용된다.
 
Command: Domain Event를 유발시키는 명령으로 주로 API와 대응된다.

Policy: 도메인 내의 규칙으로, Domain Event 뒤에 따라오는 하나의 비즈니스 로직이라고 보면 된다. Policy에 의해 다른 Event가 Trigger될 수 있다. ((예) 매월 카드 결제일이 되면 계좌에서 결제대금이 빠져나간다 )

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

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

Aggregate: 비즈니스 로직 수행을 위한 데이터 객체의 집합이라고 할 수 있다. (e.g. 주문이라는 agreegate는 배송정보, 결제정보와 같은 Domain Model(Entity)로 이루어져 있다.)
설계를 많이 경험해보지 않으면, Aggregate를 나누고, 정의하기가 참 어렵다고 한다,, 
하지만, Aggregate를 정의함으로써, 모델간의 경계를 잘 정의 할 수 있고, 코드의 일관성을 유지할 수 있고 도메인이 복잡할 때 더욱 힘이 발휘된다.

Bounded Context: Actor, Domain Event, Command를 고려한 하나의 집합 이라고 보면 된다. 쇼핑몰을 예로 들면, 회원 가입, 정보 수정등을 담당하는 회원 Context, 상품의 주문 및 결제를 담당하는 상품 Context, 배송을 담당하는 배송 Context가 있다. Bounded Context는 복잡한 비즈니스 도메인에서 이를 구분하고, 관리하기 위해 사용되며 각 컨텍스트 별로 담당하는 조직이 나뉘기도 한다. 또한, Architecture로 분리된다.
 
 
 

---

Design 과정 으로 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이 담고 있는 정보)에 대해 정의한다.
 
 
이를 바탕으로 직접 작성해보고 추가로 올려볼 생각이다!
 
 

---

REST(REpresentational State Transfer)?
 
REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.
 
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.
 
결국 이름 처럼 상태의 전이(State Transfer)를 표현하기 위한 HTTP 상의 아키텍쳐 스타일이다.

여기서 State는 Resource의 State를 표현하며, 이 Resource는 파일, 문서, 데이터 등을 모두 포함한다. 우리는 데이터를 응답해주는 역할을 하고, 이 데이터는 위에서 우리가 정의한 Domain Model에 대한 데이터이기 때문에, Resource가 Domain Model을 칭한다고 보셔도 무방하다!

이제 Resprensentation(표현)이 핵심인데,  HTTP를 사용하기 때문에 이 프로토콜을 활용해 표현한다. 아래가 바로 표현을 위한 구성 요소 라고 볼 수 있다.
 
URI(Resource) - 먼저 URI 를 통해 Reousrce 이름을 표현합니다. /models 이런식으로!
Method(Verb) - HTTP의 Method를 사용해 상태를 변경하는 행위(Verb)를 표현한다.
 
 
 
CRUD Operation?

CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로 REST에서의 CRUD Operation 동작 예시는 다음과 같다.
 
Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)
 
 
 
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을 사용할 예정이라고 한다!
 
 
 

---

REST Style API 디자인 가이드

URI, 즉 Resource의 이름은 명사, 소문자, 복수형을 사용하길 권장한다. /posts 이런식으로! /getPosts 이런식으로 동사를 사용하는걸 지양해야한다.

/ 를 통해 Resource 관의 계층 관계를 표현한다. / 는 has 를 의미한다고 보시면 됩니다! 예를 들어 특정 포스트에 달린 댓글들을 URI로 표현한다면, /posts/{id}/comments 이렇게 된다는 걸 알 수 있다.

URI 마지막에 / 를 포함하지 않는다. /posts/ 이런 형태는 지양한다!

밑줄 (_)은 사용하지 않아야하고, 가독성을 높이려면 하이픈(-)을 사용한다! /posts/{id}/long-comments 이런식으로~

특정 Resource 하나를 가져올때에는 URI에 해당 Resource의 Identifier를 포함하여 표현한다. /posts/{id} 이런식으로!

Resource 목록의 페이징(Paging), 필터링(Filtering), 정렬(Sorting), 검색(Searching)을 통해 정보를 가져올시, 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, 게이트웨이 역할을 하는 서버가 뒷단의 서버로 부터 잘못된 응답을 받았음을 알림.
 
 

예시를 들면 이런식으로 작성하는 것이라고 한다. 참고해서 내가 쓸때 응용해보아야겠다~!!

글 목록의 조회: 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}
 
 
 

---