-
비즈니스 로직 패턴
- 트랜잭션 스크립트 패턴
- 서비스 관련 메서드에 비즈니스 로직을 기술하여 표현 계층의 요청을 처리
- 동작의 구현과 상태를 보관 하는 클래스가 분리되어 있음
- 단순한 비즈니스 로직에 적합
- 도메인 모델 패턴
- 상태/동작을 가진 클래스를 정의
- 설계 이해에 용이, 테스트 용이 , 설계 패턴 적용 용이
- 도메인 주도 설계
- 어플리케이션 전체 도메인 모델의 문제점을 방지
- 애그리거트, 경계(Context Bound), 애그리거트 루트 식별이 가장 중요
- 사가(하기 기술) 와 매우 잘 어울림
- 애그리거트는 중요한 변경이 발생할 때 도메인 이벤트를 발행한다.
-
이벤트 소싱
- 이벤트를 중심으로 비즈니스 로직을 작성하고 도메인 객체를 저장하는 비즈니스 로직 구성 방법
- 애그리거트를 이벤트 저장소에 연속적으로 저장
- 사가,NoSQL와 매우 잘 어울림
- 사가 오케스트레이터를 구현하기에 매우 좋음.
- 어플리케이션은 이벤트를 재현(REPLAY) 하여 현재 상태를 재 생성
- 장점
- 애그리거트의 이력 보존으로 감사/통제 용이
- 도메인 이벤트가 확실하게 발생
- 과거 데이터의 재현 가능
- 영속성 DB와 불일치 문제를 방지
- 단점
- 비즈니스 로직 작성 방법이 달라 러닝 커브가 존재
- CQRS( 하기 기술 ) 패턴을 적용해야 유용하게 이벤트 저장소 쿼리가 가능
- 데이터 실 삭제가 어려움
- 이벤트 개량의 어려움( 데이터를 전부 업데이트 해야 할 수도 있음 )
- 예시
| EventID |
EventType |
EntityType |
EntityID |
EventData (Json) |
| 102 |
Created |
Order |
101 |
Data… |
| 103 |
Approved |
Order |
101 |
Data… |
| 104 |
Shipped |
Order |
101 |
Data… |
| 105 |
Delivered |
Order |
101 |
Data… |
- 비즈니스 로직 구성
- 2단계로 구성
- 입력 객체의 상태를 변경하고 이벤트 목록 반환
- 이벤트를 매개변수로 받아 다른 애그리거트를 업데이트
- 이벤트 저장소의 성능 개선
- 너무 많은 이벤트가 저장되어 상태가 변이되면 성능 하락
- 스냅샷 저장소를 이용하여 중간 단계 이후부터 재현하여 현재 상태를 로드
- 또는 기존의 이벤트 데이터를 정제하여 유용한 상태만을 남기도록 변경
- 예시
| EventId |
EntityType |
EntityId |
SnapShot(JSON) |
| 103 |
Order |
101 |
Data… |
| 105 |
Order |
101 |
Data… |
-
마이크로 서비스 쿼리 구현
- MSA에서는 분산 데이터를 이용하여 필요한 데이터를 조합하고 원하는 결과를 구하기가 어려움
- API 조합 패턴: 서비스 클라이언트가 여러 서비스를 직접 호출하여 결과를 조합
- CQRS: 쿼리만을 지원하는 하나 이상의 뷰 전용 DB(주로 NoSql)을 이용하는 방법.
-
API 조합 패턴
- 서비스 클라이언트가 직접 호출하는 구조로 두 가지로 파트를 분해 할 수 있다.
- 프로바이더 서비스: 최종 결과로 반환할 데이터의 일부를 가진 서비스
- API 조합기
- 프로바이더 서비스를 쿼리하여 데이터를 조회한 후 전부 합쳐 데이터를 제공한다
- 클라이언트 또는 API 게이트웨이, 백엔드 패턴 서비스(하기 기술)가 될 수 있다.
- API 조합의 설계 이슈
- 클라이언트 조합: 서비스 네트워크가 느리거나 방화벽 외부라면 불리함.
- API 게이트웨이 이용: 쿼리가 외부 (모바일, 웹) API 중 일부라면 타당함.
- API 조합기(별도 서비스): 내부적으로 여러 서비스가 이용하는 API가 많다면 유용. API 게이트로 만들기에는 너무 복잡한 쿼리에도 매우 유용하다.
- 단점
- 오버헤드 증가: 네트워크, DB 쿼리 비용 증가
- 가용성 저하: 여러 서비스가 전부 실행 중 이어야 한다.
- 데이터 일관성 저하: 서비스 별로 상태값이 다르게 존재할 가능성 존재
-
CQRS
- 데이터를 조회하기 쉬운 형태로 저장하는 데이터베이스를 가진 서비스를 구축. 또는 서비스 자체적으로 쿼리의 경우 이 데이터베이스를 통해 조회
- API 조합 패턴으로 구현이 어려운 쿼리를 조회하기가 쉬움
- 커맨드/ 도메인 모델이 변경될 때 이벤트를 발생시켜 쿼리 데이터 베이스의 View 데이터를 변경
- 장점
- MSA에서 쿼리를 효율적으로 구현 가능
- 이벤트 소싱 어플리케이션도 쿼리가 유용해짐
- 관심사의 분리가 쉬움
- 단점
- 아키텍처가 더욱 복잡해짐
- 복제 시차 문제가 생김.
- 설계 시 주의 할 점
- 데이터 베이스의 선택 ( 문서형 디비, 텍스트 검색 엔진, 그래프 DB 등 )
- 데이터 접근(뷰 빌드) 모듈 설계 시 멱등성, 동시 업데이트 고려
- 기존 어플리케이션의 스키마 변경 시 효율적으로 리빌드 할 방법 고려
- 복제 시차 처리, 동시 업데이트, 중복 이벤트에 의한 업데이트
-
외부 API 패턴
-
보안
-
구성 (Configuration )