≣ 목차
DDD란?
도메인을 중심으로(도메인 로직에 초점을 두고) 설계 및 개발을 진행한다.
- 도메인
- 비즈니스 도메인 (콘서트 예약하기 시스템)
- 해결하고자 하는 문제 도메인(시스템 내부의 콘서트, 예약, ...)
client, server 커뮤니케이션을 위해 유비쿼터스 language 를 정의한다.
- 유비쿼터스 language: 상품, 주문, ...
DDD의 핵심
- 전략적 설계: 추상화
- 전술적 설계: 아키텍처, 비즈니스 구현
SQL-DD와 DDD의 차이
SQL-DD: 객체가 가져야할 데이터를 중심으로 설계하는 방식
- 코드의 결합도가 높은 단점을 가진다.
- DDD 가 러닝 커브가 좀 더 높음
- SQL-DD 는 결합도가 높은 편(한 객체에 모든 게 들어있기 때문)
DDD 구성요소
Bounded Context
해결하고자 하는 문제 범위
1개 이상의 Aggregate 로 구성되어 있음
Context Map
Bounded Context 간의 관계에 대해 정의
주문 <-> 상품
Upstream: 상품 쪽에서 상품 정보 제공
Downstream: 소비하는 주문 쪽
Aggregate
문제 도메인을 해결하기 위한 모델의 집합
Entity, VO의 묶음
User > Point 인 경우, User 가 Aggregate Root 이다.
Aggregate Root 에서 제공하는 기능을 통해서 변경, 추가, 삭제가 가능하다.
Aggregate 에서 제공하는 핵심 비즈니스 로직을 보유한다.
예시) 유저의 포인트를 충전한다.
-> 일관성, 트랜잭션 범위 관리 용이, 유지 보수 용이 장점을 가지고 있다.
주문이 삭제되면 주문에 연관되어 있는 상품들이 삭제되어야 한다.
-> Aggregate 에 속한 모델들은 동일한 라이프사이클을 따른다.
Entity
테이블 모델
고유 식별자를 가진다.
jpa 영속성을 끊기 위해 따로 도메인 모델을 사용했다.
Value Obejct
데이터 표현 모델
불변 타입
데이터를 변경해야 할 때, Value Obejct를 새로 생성하여 교체하는 방향으로 사용하는 제약을 둔다.
Etc
DDD / MSA 별개!
Bounded Context 영역이 뚜렷하게 나뉘어서 시너지 효과는 있지만, 무조건 좋다고는 할 수 없다.
개발해야하는 서비스의 설계에 따라 DDD or SQL-DD 설계를 선택할 수 있다.
가벼운 설계에서는 SQL-DD 가 나을 수도~!
이벤트 소싱
변경되는 상태를 모두 이벤트로 관리하는 것
도메인 설계 진행해보기
상품-주문 도메인 설계 진행
JPA
jpa OOP 를 사용하기 위한 추상화
hibernate 에서 직접적인 구체화를 한다.
코드 레벨에서 신경 쓸 부분이 없어지고 비즈니스 로직에 신경을 쓸 수 있음
JPA
Repository -> JPAReposiotry -> (hibernate) JPQL -> (JDBCAPI) SQL <-> data -> (hibernate) mapping
QueryDSL (확장판 느낌)
Repository -> dynamic query -> (hibernate) 이하동문...
OSIV = true / false
- true 일 경우: http 요청이 들어올 때 영속성 컨텍스트의 범위가 view 까지 생성되고, Lazy loading 이 발생하더라도 영속성 관리가 가능하다. 영속 상태이다.
- false 일 경우: 영속성 컨텍스트의 범위가 transaction 에 국한되어 있다. 준영속 상태이기 때문에 범위 내에 없는 Lazy loading 은 인지할 수 없다.
트랜잭션이 끝났거나, 다시 조회됐을 때 `더티 체킹`때문에 DB 데이터가 수정된다.
도메인 객체와 entity 를 나눈 이유는?
영속성 관리를 받지 않기 위해서 도메인 객체와 entity 를 나눔
비즈니스 관리 모델, 엔티티 모델
MSA
기능(행위) 기반으로 분류
Filter, Interceptor
http 요청이 들어오면 servlet 이 생성되고, 스레드도 생성된다.
- servlet 내부에 filter가 있다.
spring context == spring mvc (controller, service, repository)
- spring context 내부에 interceptor 가 있다.
Dispatcher Servlet 이 Handler Mapping 을 통해 controller 를 찾아서 A
- Filter: servlet 이 실행되면 http 요청을 가장 먼저 처리하는 부분
- Interceptor: Spring Context 부분에서 controller 전에 먼저 요청을 처리하는 부분
Kafka
이벤트 스트리밍 플랫폼
고가용성 보장!
offset 으로 메시지 발행 확인
메시지를 발행한 후에 서버가 죽더라도 메시지 유실이 되지 않기 때문에 고가용성을 보장한다.
Spring event 는 서버가 죽으면 메시지가 유실된다.
transactional outbox pattern : 서버에서 메시지를 보낼 때 고가용성이 보장되지 않기 때문에 도입
DB에도 저장한다.
+ 데이터베이스 페이지네이션도 offset으로 관리한다.
댓글