몇가지 구현 이야기

본 내용은  JSP,SPRING, JPA 저자로 유명하신 최범균님의

KSUG Seminar 강의 내용을 바탕으로 작성하였습니다.

관련 유튜브영상은  요기를 클릭해주세요

 

1.DIP

 

Dependency -Inversion Principle

인프라에 의존시 고수준과 저수준이 뒤섞임. 즉, 저수준이 고수준에 영향을 줌

 

고수준 모듈: 의미 있는 단일 기능을 제공하는 모듈

저수준 모듈: 고수준 모듈의 기능을 구현하기 위해 필요한 하위 기능의 실제구현

 

ReserveService : 예약을 위한 응용로직 ->고수준

Java API로 메일을 발송 ->저수준

 

요구사항 변경 

고수준 입장에서 저수준 구현을 추상화해서 의존을 뒤집음

현재 reserveService(고수준)->JavaMailService(저수준) 였다면

 

ReserveService(고수준)->interface EmailService를 만듬(고수준)

JavaMailService는(저수준) EmailService의 구현체로 만듬 (의존의 역전)

 

고수준 모듈 입장에서 끊임없는 추상화 연습이 필요하다

 

 

 

2. Aggregate

 

개념적으로 하나인 객체 군

 

 

1)정의

 

애그리것: 관련된 객체들의 묶음

 

2)특징

 

데이터 변경시 한 단위로 처리 됨

비슷한 또는 거의 유사한 라이프사이클을 갖는 객체들

특히, 삭제시 함께 삭제됨

기본적으로 한 애그리것에 속한 객체는 다른 애그리것에 속하지 않음

 

3) 필요성

 

많은 도메인 모델을 가능한 간단하고 이해가능한 수준으로 만들 필요

연관의 개수를 즐임으로서 복잡도 감소

 

 

4)AGG 경계 

 

(1)규칙 ,트랜잭션 범위

 

Showing   상영관리자가 영화일정을 추가해도 영화 정보는 바뀌지 않음

Movie: 컨텐츠 담당자가 영화 출연자 정보를 변경해도 상영일정은 바뀌지 않음

 

동시성 처리를 할때, Movie를 변경하는 동안 관련 Showing을 잠글 필요가 없음

 

(2) SRP

Movie는 영화 정보 제공하는 책임만 갖도록 구성

할인 계산은 별도 모듈로 분리

 

5) AGG간 참조의 잠재적 문제

 

1.편한 탐색을 오용..

2.고민 Lazy Loading vs Eager Loading vs osier

3.확장방해(마이크로서비스로의 확장 힘듬)

 

AGG간 ID로 참조하기

서비스단에서 불러온다

 

특징

1.복잡도 낮츰 (모델,구현 복잡도)

2. 오용방지(응집도 강화)

3. AGG별 확장가능

4. 조회성능 영향(별도 모듈)

 

 

3. CQRS

도메인 모델로 뷰 처리..

 

복잡한 도메인의 조회 기능 특징

여러 AGG에 걸쳐 데이터 접근

성능 중요-최대한 빨리 사용자에게 화면을 제공해야함

고민 -한방쿼리, 레프트 조인, DB전용기능

 

 

상태 변경 모델과 조회 모델 분리

조회 전용 모델을 만들어라.

 

상태를 바꾸고 싶은 모델은  jpa이런거로..

상태를 바꾸는거는 애그리것내에서 이루어짐

 

조회를 하는 모델은 sql이나 mybatis 사용…

 

 

 

 4. 이벤트+비동기

 

1)정의

 

과거에 벌어진 어떤것- 주로 상태의 변화

 

이벤트 예

영화 추가함

예매함

영화 상영일정 추가함

영화 정보 변경함

영화 가격정책 변경함

예매 취소함.

 

 

2) 이벤트의 구성

 

구성- 발생주체(주로 식별자), 일련번호/버전, 타입,발생시간, 내용(payload)

 

예)

회원 암호 변경 이벤트

발생주체 : ㅇㅇㅇ

버전 1

타입 passwordChangedEnent

발생시간: 2016-05-05

내용 : {id :”mad”, newPwd: “xxx”}

 

 

3) 이벤트 관련 구성 요소

 

이벤트 생성 주체

이벤트 디스패처(이벤트 퍼블리셔)

이벤트 핸들러

이벤트 

 

 

4) 이벤트 용도

 

(1)트리거

다른기능을 수행하기 위한 트리거로 이벤트 활용

예시. 예매를 하면 sms로 통지한다.  예매함 이벤트->SMS 통지 트리거

예매를 취소하면 환불한다. 예매취소이벤트->환불트리거

 

예매취소-예매취소된 이벤트 -> 이벤트 디스패치—예매 취소된 이벤트->예매 취소됨. 이벤트 핸들러->환불처리

 

 

(2)데이터 동기화

다른 시스템 간 데이터 동기화 목적으로 이벤트 사용

예시 상영 일정 추가 이벤트 헨들러 ->조회 전용 저장소에 추가 데이터 반영

 

 

상영일정 추가(->커맨드 모델 저장소) —일정 추가됨 이벤트—>이벤트 디스패치—일정추가됨 이벤트—>일정 추가됨 이벤트 핸들러->일정 데이터 추가(쿼리모델 저장소)

 

 

도메인과 이벤트

도메인의 상태 변경을 이벤트로 표현

~할때, ~가 발생하면 ,만약~하면 등의 요구사항이 실제로 상태 변경인지 확인

예시)영화 정보를 변경할때 —>MovieInfoChangedEvent

예매를 취소하면 —>ReservationCanceledEvent

 

 

5) 이벤트 적용 장점

 

(1) 서로 다른 도메인 영역의 로직이 섞이는 것 방지

불필요한 결합 제거

 

예매취소-예매취소된 이벤트 -> 이벤트 디스패치—예매 취소된 이벤트->예매 취소됨. 이벤트 핸들러->환불처리

 

위의 예매취소와와 환불 처리 : 예매 취소에 더이상 환불 로직이 없음.알필요도 없음. 예매 도메인에서 환불 도메인으로의 의존 제거

 

(2) 이벤트 핸들러 추가로 기능확장

예매취소 —예매취소된 이벤트—이벤트 디스패치 —예매취소된 이벤트—예매 취소됨 에벤트 핸들러1 ->환불처리

                          —예매취소된 이벤트—예매 취소됨 에벤트 핸들러12->이메일통지

 

이게 곧 ocp (나를 안 바꾸면서 나를 확장하는거)

 

 

6) 기타

 

동기 이벤트 처리의 단점

-트랜잭션 처리문제, 성능(처리량) 문제

 

비동기: 이벤트 처리 시간

A할때 B해라. 요구사항에서 A와 B의 간격 도메인 전문가의 바로는 즉시실행이 아님 수용가능한 허용범위가 있음

예시 예매취소시(늦어도 30분 이내에)환급처리함

결제 완료후, (늦어도 다음날 7시 부터)배송 상태를 조회할 수 있어야함

티켓 예매시, (최대10분안에) 분 단위 티켓 판매 통계에 반영함 (분단위 티켓 판매 통계가 10분 주기로 생성되어도 대세 지장없음)

 

 

비동기: 이벤트와 데이터 일관성

A할때 B해라. 요구사항에서 A와 B의 일관성 -실제로는 한 트랜잭션이 아닌 경우가 많음

예시 이메일 바송 실패한다고 회원 가입을 못하지 않음

고객이 예매 취소하면, 운영자가 수동으로 환불처리 가능

 

 

비동기 이벤트의 특징

이벤트 생성자와 핸들러의 트랜잭션 분리

처리량 향상 -고객에게 빠른 응답

구조가 복잡해짐

재발송, 재처리 등 고려 사항 증가

 

 

7) 이벤트 처리 방식

 

출처: 최범균님 KSUG Seminar 강의

 

출처: 최범균님 KSUG Seminar 강의

 

출처: 최범균님 KSUG Seminar 강의

 

출처: 최범균님 KSUG Seminar 강의

 

 

8) 이벤트 도입시 고려사항

 

이벤트 도착 순서

이벤트 발송 실패시 재발송

이벤트 재처리