[빗썸테크아카데미] 여섯번째 - 웹서비스 API , DDD

 

 

[빗썸테크아카데미] 여섯번째 - 웹서비스 API , DDD

 

 

저번 수업부터 매일 쓰는 회고의 방식이 바뀌었는데

맨 밑에 오늘의 질문이 추가되었다.

 

그래서 오늘 배운 수업에서 오늘의 질문이 있으면

그질문을 모아 다음날 수업 시작전에

답변을 하고,

그다음 수업을 진행하는 방식으로 변경되었다 :)

 

개인적으로

다양한 질문들에 대한 답변을 들을 수 있어서

좋은 방법이라고 생각되었다.

 

 

 

---

 

1. 웹의 작동 원리

Q. 브라우저의 주소창에 www.naver.com을 입력 후 네이버 메인 화면이 브라우저에 로딩되기까지 일어나는 일련의 과정은 어떻게 되는가? 

1. 브라우저는 https://www.naver.com 의 IP를 DNS에 요청

2. DNS로부터 IP를 받아온다.

3. 해당 웹서버에 Initail document를 요청 = 내가 여기 처음 왔으니 뭐라도 내놔라!

4. 웹서버는 뭐라도 줘야하니까 갖고 있던 static document를 전달 ex) index.html

5. 이렇게 시간을 벌어두고 웹서버는 동적인 Data를 요청

6. 내부 로직을 처리

7. 처리된 Data를 웹서버에 전달

8. 동적 Data를 브라우저에 전달

 

 

 

2. 웹 서비스 API

2.1. SOAP

• 약속한 xml 규약을 갖고 통신
• 규약을 미리 알고 있어야만 통신 가능
• 깐깐한 프로토콜 덕분에 보안이 좋음
• 지금은 거의 사용되지 않음

 

2.2. REST

• 서비스의 동작보다 전달되는 자원에 관심을 둔 API Design
• Resource : HTTP URI
• Opertaion : HTTP method 중 GET, POST, PUT, PATCH, DELETE, HEAD 사용
• Representation : 주로 JSON 형태, HTTP에서 지원하는 다양한 형식 가능
• Stateless : Client의 context를 server가 저장하지 않음. 동일한 요청도 매번 별개의 동작으로 처리
• Cacheable : HTTP의 캐싱 기능 활용. 대량 요청 처리 용이
• Layered : 네트워크 기반 중간 매체(proxy, gateway) 활용
• Uniform Interface : HTTP 표준 프로토콜 준수

 

2.3. GraphQL

• API를 위한 Query Language
• Resource당 하나의 endpoint
• 요청 시 원하는 리소스에서 필요한 컬럼을 특정하는 query 형태
• FE-BE 생산성 향상
• FE에서 데이터 구조에 대한 이해가 있어야 함

 

 

2.4. gRPC

• MSA 처럼 내부 호출이 잦은 경우 사용
• Remote Procedure Calls : Client가 Sever 내 원격 Procedure를 호출                                                                ->클라이언트가 프로토콜 버퍼를 보내서 서버의 프로시저를 실행 할 수 있음
• Client에서 Server 기능을 local처럼 사용
• gRPC는 바이트 코드를 주고 받기 때문에 Json보다 경량화

 

 

 

 

 

3. Domain Driven Development

3.1 기존의 개발

• 관계형 데이터 모델에 종속
• 최초 설계 데이터의 모델링의 변경/확장 대응 고려 X
• 모델링과 실제 개발의 불일치 누적

 

3.2 도메인 주도 설계

• 실제 비즈니스와 개발 결과물의 동작을 최대한 일치
• 용어 사전을 기반으로 한 도메인 중심 설계
• 설계와 구현은 계속해서 수정될 수 있음

※용어 사전(Ubiquitous Language)※

: 사용자와 설계자, 구현자가 모두 의미에 동의할 수 있는 용어의 모음

ex) impression 

 -> 사전적 정의 : 인상, 감명

 -> 광고 대행사의 domain : 광고가 노출되는 횟수

 

 

3.3 Domain 이란?

• 소프트웨어로 해결하고자 하는 문제 영역
• 개발하려는 서비스의 비즈니스 로직과 연관

EX) 음식 배달 서비스 - 음식점 관리, 주문, 배달 연계

     쇼핑몰 서비스 - 상품관리, 주문, 배송

     의무 기록 서비스 - 환자 관리, 의학적 상태, 진단

     주식 거래 서비스 - 주식 정보, 주가 정보, 거래

 

 

3.4 Domain Model

• 요구사항으로부터 Domain과 이하 Entity를 정의하고 그 관계를 경계와 함께 추상화한 모식도

 

 

3.4.1 Object vs Domain

 

Object 

• 추상화하거나 구체화할 수 있는 대상
• ex) 상품, 주문, 쿠폰, 결제 방법...

 

Domain

• 요구사항에서 표현하는 모든 것
• ex) Object + 주문하다, 결제하다, 정산하다....

 

 

3.5 Domain Driven Design Step

1) 요구사항 정리

2) 핵심 도메인 로직 파악

3) 용어 사전 정리

4) 도메인을 작은 단위로 분리

5) Bounded context 설정하고 관계 정의

6) 세부 동작 설계

7) Context별 Bounds 침범 여부 확인

8) 변경 사항 발생 시 반복

 

 

 

3.6 Domain Driven Development

Domain model pattern

• Entity
• Value Object
• Service
• Aggregate
• Repository

 

Bounded Context

• 서로 독립적인 업무로 분할될 수 있는 모델 영역
• MSA를 나누는 단위로 사용 가능

 

 

4. Domain Driven Architecture

 

Presentation layer

• Client의 요청을 받고 App layer로부터 전달받은 결과를 Client에게 다시 전달

 

Application layer

• Client에게 제공할 결과를 Domain layer에 요청하여 조합

 

Domain layer

• Domain model을 구현

 

Infrastructure layer

• DB, 외부 시스템등 연동 처리

 

 

 

 

---

 

이번주는 온라인 강의 학습 커뮤니티에 대한 시나리오를 주고

거기에 맞는 도메인 주도 설계를 짜보는 과제가 나왔다.

금요일 수업 전까지 제출하면

그걸로 금요일에 페어 리뷰를 진행한다고 하셔서

오늘은 과제가 없나보다 했는데

 

갑자기 급!!과제를 내주셨다 ㅋㅋㅋ

 

바로 WebFlux를 이용해서 간단한 서버 구축해보기!

 

Spring 5+ (Spring boot 2+), Java 8 +, WebFlux, Functional Endpoint를 사용해서

GET localhost:8080/hello?name=$name 요청을 받고

JSON으로 response 하는 서버 구현하기!

 

간단하지만

처음 써보는  WebFlux, Functional Endpoint로 구현하라고 해서

두근두근 설렌다

 

 

얼른 해봐야지