Project 통합택배조회 api 01편 (프로젝트 개요)
Created Time: August 30, 2022 1:04 PM
Last Edited Time: September 16, 2022 2:43 PM
Tags: Java, Spring, Computer
프로젝트 개요
각 회사의 api를 이용하여, 배송지 추적을 손쉽게하는 통합 API 만들기
프로젝트 스펙
spring boot - 2.7.3
java 11
packaging - jar
dependencies
프로젝트 진행시 추가 예정1
2
3
4
5
6
7
8
9
10
11dependencies {
implementation 'org.springframework.boot:spring-boot-starter-security'
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
implementation 'org.springframework.boot:spring-boot-starter-validation'
implementation 'org.springframework.boot:spring-boot-starter-web'
implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity5'
compileOnly 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
testImplementation 'org.springframework.security:spring-security-test'
}
프로젝트 구현 순서
api로만 구현해서 대표적인 cj대한통운, cu post만 구현, 내부 통신 구조 설계
DB설계
아키텍쳐 설계
도메인(역할별나누기), 클래스 다이어그램(인터페이스, 클래스 의존관계), 객체 다이어그램(실제 동적결정이므로 실제로 쓰이는 객체) 그려보기
kafka 도입
- 1번 진행시 MSA로 consumer와 producer를 미리 생각하여 구조설계하자
마지막 카카오톡 채널과 연결
- https ssl인증필요
- aws
- docker필요할지도?
- 고유링크로 만든 페이지쪽으로 이동(트레픽생각하기)
- kakao_id로 유저인증? jwt token사용? 카카오브라우저는? 쿠키 사용가능?
- referer 참조해서 해결?
프로젝트 필요한 정보 및 지식
- 각 택배 회사에 대해 API 뜯어보기
- 카카오톡 응답시 요구되는 응답시간 → 반드시 링크로 처리해야되는지 체크
MSA 고려
이유: 모노로직아키텍처는 scale out에 불리하며, 책임이 나눠져있지않으므로, 구성하는 하나의 서비스만 에러가 난다면, 전체에 영향을 준다. 따라서 서비스 별로 분리를 통해 이와같은 문제를 해결하고자하였다.
외부 API(end-point)(접근점)만 노출되고, 작은 서비스의 조합으로 동작한다.→ scale out과 장애발생시 쉽게 부분적 픽스가능)(mono와 반대개념)
내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
제대로 설계 된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. 그리고 여러 어플리케이션에서 재사용할 수 있어야 한다.
통신 kafka 사용
각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 메모리, CPU적으로 상당부분 이득이 된다.
UML(Unified Modeling Language)
UML이란?
통합 모델링 언어
모델을 만들고 설명하는 표준 언어
클래스 다이어그램
구조 다이어그램 중 하나
클래스의 속성, 함수, 변수타입들로 구성된 다이어그램
클래스의 세부사항은 필드와 메서드의
접근 제한자(Access modifier),필드명(메서드명),데이터 타입,매개변수(parameter),리턴 타입등을 나타낼 수 있다.(필요한것만 목적에맞게 넣자)- 접근 제한자 (Access modifier)
+: public- `` : private
#: protected
- 속성 (Attribute)
- 접근제어자 이름: 타입 = 기본값
- 기본값 생략 가능
title: String = ""
- 기능 (Method)
- 접근제어자 이름(파라미터 속성): 리턴값
- void 리턴값은 생략 가능
+ setTitle(String)+ getTitle(): String
- 접근 제한자 (Access modifier)
Stereo Type
- UML에서 제공하는 기본 요소 외에 추가적인 확장 요소를 나타내는 타입입니다.
- 길러멧 기호 («») 사이에 적습니다
- interface, utility, enumerate, abstract등등있음
Class Relationship
일반화
부모(슈퍼) 클래스와 자식(서브) 클래스 간의 상속 관계 (Inheritance)를 나타냅니다.
부모 클래스는 자식 클래스를 일반화한(Generalize) 것이고, 자식 클래스는 부모 클래스를 구체화한(Spectialize) 입니다.
실선 삼각형 화살표!
실체화(Realization)
interface의 기능을 실제 기능으로 구현하는 것을 의미합니다.
인터페이스와 클래스 사이의 Relize 관계는 점선과 인터페이스 쪽에 비어있는 삼각형 화살표
의존(Dependency)
- 어떤 클래스가 다른 클래스를 참조하는 것을 의미
합니다. - 클래스 사이를 점선과 참조할 클래스에 화살표를 선으로 그려 표현합니다
- 참조의 형태는 아래와 같습니다.
- 메서드 내 대상 클래스 객체 생성
- 메서드 내 대상 클래스 객체 사용
- 메서드 내 대상 클래스 메서드 호출
- 메서드 내 대상 클래스 객체 리턴
- 메서드에서 대상 클래스 객체를 매개변수로 받는 것
- 이와 같은 객체 참조는 계속 유지하지 않고 메서드의 호출이 끝나면 의존 관계의 클래스와 관계가 끝납니다.
- 어떤 클래스가 다른 클래스를 참조하는 것을 의미
연관 (Association, Directed Association)
클래스 다이어그램에서의 Association은 보통 다른 객체의 참조를 가지는 필드를 의미
합니다.위의 다이어그램은 두 가지 형태의 Association 을 나타내고 있습니다.
- 일반적인 Association실선 하나로 클래스를 연결합니다.방향이 없으므로
User가Phone을 참조할 수도,Phone이User를 참조할 수도, 둘 다일 수도 있습니다. - Directed Association클래스를 실선으로 연결 후 끝에 화살표를 추가합니다.
User에서Phone으로 화살표가 향하고 있으므로User가Phone을 참조하는 것을 의미합니다.화살표 옆의phones는 roleName(역할명)을 나타내고 어떤 역할로 참조되는지를 의미합니다. - 두 형태의 Association 간의 차이는 방향성입니다.방향의 유무에 따라 참조하는 쪽과 참조 당하는 쪽을 구분합니다.
- `` 은 개수를 나타내는데 대상 클래스에 가질 수 있는 인스턴스 개수 범위를 뜻합니다.
1: 1개*: 0~n개n...m: n부터 m까지 연관관계를 맺음
1
2
3public class User {
private List<Phone> phones;
}- 자바로 위 다이어그램의 연관 관계를 나타냈습니다.
- 일반적인 Association실선 하나로 클래스를 연결합니다.방향이 없으므로
합성 (Composition, Composite Aggregation)
- Aggregation과 비슷하게 전체(whole)와 부분(part)의 집합 관계
를 나타내지만 개념적으로 Aggregation 보다 강한 집합을 의미
합니다. - ???
- Aggregation과 비슷하게 전체(whole)와 부분(part)의 집합 관계
시퀀스 다이어그램
해위 다이어그램 중 하나
여러 대상 간의 상호작용을 시간 순서에 따라 표현한 다이어그램
