도메인 이벤트에 대해 알아봅시다. 

 # 개요.

주문 바운디드 컨텍스트와 결제 바운디드 컨텍스트가 존재한다고 가정하자.

주문이 완료 되면 결제 해야하는 상황에서 

결제라는 외부 시스템을 주문이 의존 하는 관계가 된다. 

이때 발생 할 수 있는 문제가 크게 두 가지 있다.  

첫째.

외부 서비스가 정상이 아닐 경우 트랜잭션 처리가 애매하다.

결제 하면서 외부 시스템에 익셉션이 발생하면 트랜잭션을 롤백해야하는가?

아니면 일단 커밋 해야하는가?

둘째.

성능에 관련된 문제이다.

외부 시스템에 응답 시간이 길어질 수록 성능이 느려진다. 

이러한 문제가 발생 하는 근본적인 이유는 주문과 결제가 강한 결합을 맺고 있기 때문이다. 

이러한 강한 결합을 없애는 방법 중 하나는 이벤트를 사용 하는것이다. 

특히 비동기 이벤트를 사용하면 시스템 결합을 크게 낮출 수 있다. 

# 이벤트 구성 요소

![Untitled (54).png](https://blog.kyb.pe.kr/api/v2/file/static/911c5e2a-5ac1-4b5a-b867-aed2b09d229e)

도메인 모델에서 이벤트 생성 주체는 (엔티티, 밸류, 도메인 서비스와 같은 도메인 객체이다)

이벤트 핸들러는 이벤트 생성 주체가 발생한 이벤트에 반응한다. 

디스패처는 이벤트와 이벤트 핸들러를 연결한다. 

### 이벤트

![Untitled (55).png](https://blog.kyb.pe.kr/api/v2/file/static/d3cbfbbd-a07c-4323-a463-692d5b7ced18)

이벤트 종류: 클래스 이름으로 이벤트 종류 표현

이벤트 발생 시간

추가 데이터: 주문 번호, 신규 배송지 정보 등등 이벤트 관련된 정보

# 이벤트, 핸들러, 디스패처 구현

간단하게 스프링이 제공하는 이벤트 관련 기능을 사용해서 이벤트 발생과 처리를 구현할 수 있다.

실제로는 대부분의 경우 RabbitMQ나 Kafka 와 같은 외부 메시징 서비스를 사용한다. 

위 구현은 311page 부터  321페이지 참고. ( 비동기 메시지 처리까지 한다. 참고할 만한듯)

![Untitled (56).png](https://blog.kyb.pe.kr/api/v2/file/static/8a04ee95-f36a-4db3-96a5-7d93de9d483a)

저자가 소개하는 방식중 하나인 이벤트 저장소 방식인데.

API 통해 이벤트를 읽어와 처리 하는 부분이 폴링 하는 방식이다. 

그리고 구조 자체가 꽤나 계층이 깊고, 폴링 방식이고, 이런 모델을 직접 구현해야하는 문제가 발생하면

외부 메시징 시스템을 도입하는게 좋지않을까? 

그래서 스킵하겠다. 

# 이벤트 적용시 추가 고려 사항

![Untitled (57).png](https://blog.kyb.pe.kr/api/v2/file/static/90fe7e89-e336-401f-aa0c-39613fc036be)

트랜잭션 처리가 가장 어렵다. 

물론 글로벌 트랜잭션으로 하나의 트랜잭션으로 모두 한꺼번에 묶을 수도 있다. 

그러나 성능상 매우 떨어지는 방식이고, 카프카 같은 경우 지원도 안된다. 

### 비동기 이벤트 처리

![Untitled (58).png](https://blog.kyb.pe.kr/api/v2/file/static/e4739301-e488-4a49-81e4-bdf8f35128ab)

비동기 이벤트 처리가 어려운 이유는 발생하는 케이스가 4가지이다. 

이벤트 발생와 이벤트 처리 두 가지 부분으로 나뉘며 각각 성공 실패가 가능하다.

즉 이벤트 발생 실패, 이벤트 처리 성공 같은 케이스가 가능하다. 

이 때문에 비동기 이벤트 처리가 어렵다. 

책에서는 

![Untitled (59).png](https://blog.kyb.pe.kr/api/v2/file/static/2649e273-8933-441c-a553-8d65b2d02c09)

위와 같은 설정으로 이벤트 발생이 커밋이 됐을때만 이벤트 핸들러가 호출 되도록 설정 했다.

따라서 이벤트 발생 실패, 이벤트 처리가 진행이 안되도록 설정 한것이다.

DDD 시작하기 정리 -8 이벤트

바운디드 컨텍스트에 대해 알아봅시다. 

 # 바운디드 컨텍스트 개요

처음 도메인 모델을 만들 때 빠지기 쉬운 함정이 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것이다. 

그러나 한 도메인은 다시 여러 하위 도메인으로 구분 되기 때문에 

한 개의 모델로 여러 하위 도메인을 표현할려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만든다. 

예를 들어서 상품이라는 모델을 생각해보자.

카탈로그에서 상품

재고 관리에서 상품

주문에서 상품

카탈로그에서 상품은 상품 이미지, 상품명,  상품 가격, 옵션 목록, 상세 설명과 같은 상품 정보가 위주라면

재고 관리에서는 실존하는 개별 객체를 추적하기 위한 목적으로 상품을 사용한다. 

위와 같이 같은 상품이라도 도메인에 따라 다르게 해석 되어야하는 모델이 있는가 하면

논리적으로 같은 존재로 보이지만 하위 도메인에 따라 다른 용어를 사용하느 경우도 있다. 

시스템을 사용하는 사람을 회원 도메인에서 회원이지만

주문 도메인에서는 주문자라고 부르고

배송 도메인에서 보내는 사람이라고 부른다. 

![Untitled (43).png](https://blog.kyb.pe.kr/api/v2/file/static/0586d5d1-0bf5-470e-94c3-f836935c239a)


이렇게 하위 도메인 마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수 도 없다.

하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발할려면 하위 도메인 마다 모델을 만들어야한다. 각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야한다. 

이러한 경계를 바운디드 컨텍스트라고 한다. 

바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 

구현하는 하위 도메인에 알맞은 모델을 포함한다.

회원은 회원 바운디드 컨텍스트에서 애그리거트 루트지만

주문 바운디드 컨텍스트에서는 주문 애그리거트에서 Orderer로서 밸류가 된다. 

# 바운디드 컨텍스트 구현

![Untitled (44).png](https://blog.kyb.pe.kr/api/v2/file/static/e3f93e49-f7cd-407b-bbb1-97d5bf1937e6)

물론 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다. 

![Untitled (45).png](https://blog.kyb.pe.kr/api/v2/file/static/aad44ffd-3525-4914-8535-b809e7275f59)

상품의 리뷰는 복잡한 도메인 로직을 갖지 않으므로 CURD 방식으로 구현하면 된다. 

그리고 한 바운디드 컨텍스트안에서 두 가지 혼합해서 사용할 수도 있다.

이게 CQRS 패턴이다.

![Untitled (46).png](https://blog.kyb.pe.kr/api/v2/file/static/e6e70516-bc47-4187-bdf4-9182fcfb260c)

CQRS는 읽기와 쓰기를 분리하는것이다.

참고) CQRS

사실 대부분의 도메인 로직은 쓰기에서 발생 한다. 

즉 쓰기에서 복잡하고 어려운 도메인을 구현하고.

읽기는 간단하게 개발하는것이 CQRS의 컨셉이다. 

예를 들어서 쓰기로 RDBMS에 모든 제약( 외래키 , unique) 다 걸어서 정말 도메인 로직에 맞게 쓰기를 하고 읽기를 할 때 NoSQL에 조인까지 다 되어서 하나의 데이터 덩어리로 넣어놓고 조회 하는 방식도 가능하다. 

# 바운디드 컨텍스트 통합

예를 들어서 온라인 쇼핑몰에서 관련 제품 추천이라는 기능이 새로 추가 된다고 생각해보자. 

그러면 기존 카탈로그 시스템을 만드던 팀과 추천 시스템을 담당하는 팀이 새로 생겨서 이 팀에서 주도적으로 추천 시스템을 만들기로 했다. 

![Untitled (47).png](https://blog.kyb.pe.kr/api/v2/file/static/0e5faccb-ccc9-43e9-b6ab-2577037e02e2)

사용자가 제품 상세 페이지를 볼 때, 보고 있는 상품과 유사한 상품 목록을 보여준다. 

이때 카탈로그 바운디드 컨텍스트와 추천 컨텍스트는 도메인 모델이 서로 다르다. 

카탈로그 시스템은 추천 시스템으로부터 추천 데이터를 받아오지만, 카탈로그 시스템에서는 추천 도메인이 아닌 카탈로그 도메인 모델을 사용해서 추천 상품을 표현 해야한다. 

![Untitled (48).png](https://blog.kyb.pe.kr/api/v2/file/static/179b8cd1-1482-4992-b8cb-55617383b5d2)

REST API로 바운디드 컨텍스트 끼리 통신을 결정하고

도메인 불일치를 인프라 영역의 DIP 해결 했다. 

물론 REST API를 호출 하는 것은 두 바운디드 컨텍스트 직접 통합 하는 방식이다. 

직접 통합 하는 방식 보다 간접적으로 통합 하는 방식도 있다. 

![Untitled (49).png](https://blog.kyb.pe.kr/api/v2/file/static/710c7c27-b84a-4af7-9a1c-fb59fd5c72ff)

REST API 경우 인프라 영역에 DIP 통해서 도메인 모델 불일치를 해결했지만

이러한 메시지 시스템의 경우에는 메시징 큐에 담을 데이터의 구조를 협의해야한다.

![Untitled (50).png](https://blog.kyb.pe.kr/api/v2/file/static/611c857a-a9a2-4aa9-8304-3421da38c455)

출판 구독 모델을 따른다면 출판 하는쪽( 큐를 제공하는 쪽)이 데이터 구조를 결정 하는것이 일반적이다. 

# 바운디드 컨텍스트 간 관계

![Untitled (51).png](https://blog.kyb.pe.kr/api/v2/file/static/146b4d2e-c036-4ee8-b81f-b6f2d510af2c)

위와 같이 고객 / 공급자 관계를 갖는 바운디드 컨텍스트는 

고객이 공급자에 데이터와 기능을 의존한다. 

(물론 DIP 이용해서 서로 간의  종속성 분리는 해야한다.)

만약 상류에 많은 하류 컨텍스트가 존재한다면

![Untitled (52).png](https://blog.kyb.pe.kr/api/v2/file/static/cc17dcbf-fe1f-4358-948f-2db5d22e3fd4)

이런식으로 각 하류 컴포넌트의 요구 사항을 수용할 수 있는 단일  API를 만들어서 이를 공개하고 각 하류 팀은 이것을 이용한다 ( 이것을 공개 호스트 서비스라고 부른다)

공개호스트 서비스의 대표적인 예제로는 검색이다. 

블로그, 카페, 게시판 같은 서비스를 제공하는 포털은 각 서비스별로 검색 기능을 구현하기보다는 검색을 위한 전용 시스템을 구축하고, 검색 시스템과 각 서비스를 통합한다. 

# 컨텍스트 맵

![Untitled (53).png](https://blog.kyb.pe.kr/api/v2/file/static/78195e2d-7fa2-48bd-a8ea-32ef08e7f8a2)

OHS (오픈 호스트 서비스)

ALC ( 안티 코럽션 계층) → DIP로 종속성 분리한 계층

DDD 시작하기 정리 -7 바운디드 컨텍스트

 일단 시작 전에 데이터베이스에서 트랜잭션의 격리 레벨과 비관적 낙관적 잠금에 대해 알아보자. 

# 트랜잭션 동시성 문제

트랜잭션의 동시성으로 발생할 수 있는 문제는 3가지이다.

- **Dirty Read**
- **Non-Repeatable Read**
- **Phantom Read**

### **Dirty Read**

1. A 트랜잭션에서 10번 사원의 나이를 27살에서 28살로 바꿈
2. 아직 커밋하지 않음
3. B 트랜잭션에서 10번 사원의 나이를 조회함
4. 28살이 조회됨
    
    > 이를 더티 리드(Dirty Read)라고 한다
    > 
5. A 트랜잭션에서 문제가 발생해 ROLLBACK함
6. B 트랜잭션은 10번 사원이 여전히 28살이라고 생각하고 로직을 수행함

격리 수준 ****READ UNCOMMITTED에서만 발생하는 문제로**** 

****READ COMMITTED 이상에서 부터 발생하지 않는다.**** 

### **Non-Repeatable Read**

가장 쉽게 설명하면 한 트랜잭션에서 조회를 했는데, 

다시 조회해보니 둘의 값이 다른 상황이 발생 

- A 트랜잭션에서 사원에 나이가 27살로 조회
- B 트랜잭션에서 사원에 나이를 28살로 커밋
- A 트랜잭션에서 사원에 나이를 다시 조회 28살로 조회, 처음 조회된 27살과 다름

 

한 트랜잭션 내에서 같은 쿼리를 두 번 수행할 때, 

**그 사이에 다른 트랜잭션이 값을 수정 또는 삭제함으로써** 

**두 쿼리가 상이하게 나타나는 비 일관성이 발생하는 것을 말한다.**

### **Phantom Read**

**하나의 트랜잭션에서 같은 쿼리를 두 번 실행했을 경우,** 

**첫 번째 쿼리에서 없던 `유령(Phantom) 레코드`가 두 번째 쿼리에서 나타나는 현상이다.**

**`INSERT`에 대해서만 발생하는 문제다. (`SELECT`, `DELETE`에 대해서는 발생하지 않는다)**

# 트랜잭션의 격리 수준

- ****READ UNCOMMITTED****
- ****READ COMMITTED****
- ****REPEATABLE READ****
- ****SERIALIZABLE****

### ****READ UNCOMMITTED****

( **Dirty Read,  Non-Repeatable Read,  Phantom Read )  전부 발생**

애초에 고려되지 않는 격리 수준

### ****READ COMMITTED****

다른 트랜잭션에서 커밋된 내용만 참조할 수 있다.

(**Non-Repeatable Read , Phantom Read) 문제 발생**

### ****REPEATABLE READ****

가장 기본적으로 선택되는 트랜잭션 격리 수준 

각 트랜잭션 별로 각자만의 읽기 버전이 있는 형태이다. ( 멀티 버전 )

오라클이나 MySQL의 경우 MVCC 패턴으로 해당 트랜잭션에 

맞는 데이터로 Undo해서 데이터를 읽어온다. 

예를 들어서 각각의 트랜잭션에 타임 스탬프가 있고,

해당 트랜잭션에 타임 스탬프보다 낮은 데이터만 읽어오는것이다. 

**UPDATE 부정합 문제**

****REPEATABLE**** READ는 make sense 하다.

트랜잭션이 시작 했을 때의 데이터를 트랜잭션 끝날때 까지 유지하겠다는 뜻이다.

이 말은 다시 말하면 트랜잭션의 시작했을 때의 데이터만 보겠다는 뜻이다. 

그러나 업데이트 경우 달라진다.

```sql
START TRANSACTION; -- transaction id : 1
SELECT * FROM Member WHERE name='hjoon';

    START TRANSACTION; -- transaction id : 2
    SELECT * FROM Member WHERE name = 'hjoon';
    UPDATE Member SET name = 'top' WHERE name = 'hjoon';
    COMMIT;

UPDATE Member SET name = 'sun' WHERE name = 'hjoon'; -- 0 row(s) affected
COMMIT;
```

결과를 예상해보자. 

- 2번 트랜잭션이 업데이트한다. ( name= ‘top’ )

예전 데이터 name = 'hjoon'는 UNDO 세그먼트에 남겨둬야한다.

- 1번 트랜잭션이 업데이트 할 때 바라보는  데이터는 레코드 데이터가 아니라 UNDO 세그먼트 영역의 데이터이다.

UNDO 세그먼트 데이터는 쓰기 잠금을 걸 수 없다.  ( UPDATE는 변경을 수행할 ROW에 LOCK을 걸어야한다 )

1번 트랜잭션은 레코드 데이터에 쓰기 잠금을 시도하지만, 더이상  name = 'hjoon 데이터가 존재 하지 않는다. 그래서 아무런 변경 없이 1번 트랜잭션 끝난다. 

### ****SERIALIZABLE****

선행 트랜잭션이 특정 테이블을 읽는 경우 

해당 테이블을 잠궈서 다른 트랜잭션에서 해당 테이블의 DML 수행을 막는다. 

동시 처리 능력이 매우 떨어져서 데이터베이스에서 사용하지 않는다. 

# 비관적 낙관적 잠금

읽기 일관성은 ****REPETABLE READ**** 이상이면 지켜진다.

그러나 update는 일관성을 지킬 수가 없다. 


이를 해결 하기 위해 두가지 방식이 있다. 

- 비관적 잠금 방식 ( Pessimisitic Lock )
- 낙관적 잠금 방식 ( Optimisitic Lock )
    
    

## 비관적 잠금

****SERIALIZABLE 격리 수준을 설명할 때 테이블을 잠금한다고 했는데.****

내가 알고 있기로는 현대 DBMS에서 테이블 전체를 잠그는 미친 DBMS는 존재 하지 않는다. 

대부분의 경우 테이블에 트랜잭션이 접근할 때, 테이블이 “ 어떤 행 지금 업데이트 중 대기하셈 ㅇㅇ” 

그러면 트랜잭션이 “어 나 그 행 업데이트 관심 없음”  그러면  테이블이 “ 그럼 진행 해”

이런식이다. 다만 격리 수준을 ****SERIALIZABLE 설정 하면 기본값이 저것이 되는것****

그러나 특정 경우에만 저런 기능을 이용하고 싶다면 사용하는것이 for update이고 이것을 비관적 잠금이라고 말한다. select * from table for update

![Untitled (39).png](https://blog.kyb.pe.kr/api/v2/file/static/675601fd-46fd-4cfb-96c8-2180e3177ac5)

![Untitled (40).png](https://blog.kyb.pe.kr/api/v2/file/static/b0167816-e9e3-4205-8b4b-a9d086300bfd)

그러나 비관적 잠금 ( 책에선 이름 병신 같다고 선점 잠금이라고 언급 *나도 이 부분은 동의*)

데드락이 발생 할 수 있다. 

자원 A,B가 있고.

a가 A 소유하고 있고,

b가 b 소유하고 있는데.

a가 B를 원하고, b가 A를 원하면 데드락 상황 발생하는것 처럼

 비관적 잠금을 이용하면 이러한 데드락 상황이 발생한다. 

그렇기 때문에 최대 시간을 지정해서 for update 쿼리를  사용 해야 한다. 

그 후 데드락을 어떻게 처리 하는지 DBMS 마다 다르다. 

## 낙관적 잠금

비관적 잠금이 모든 트랜잭션 충돌 문제가 해결되는것은 아니다.

![Untitled (41).png](https://blog.kyb.pe.kr/api/v2/file/static/178cf6aa-3325-4952-8599-cbb2b6e70689)

이 상황을 순서대로 정리하면

1. 운영자는 배송을 위해 주문 정보를 조회한다. 
2. 고객이 배송지 변경을 위해 변경 폼을 요청한다. 
3. 고객이 새로운 배송지를 입력하고, 폼을 전송하여 배송지를 변경한다. 
4. 운영자가 1번 주문 정보 기준으로 배송지를 정하고 배송 상태를 요청한다. 

운영자는 고객이 변경하기 전 배송지 정보를 이용해서 배송 준비를 한 뒤 배송 상태로 변경한다. 

즉 배송 상태 변경 전에 배송지를 한 번 더 확인하지 않으면 운영자는 다른 배송지로 전송한다. 

**이 문제는 비관적 잠금을 해결할 수 없다.**

( 나 이 부분이 이해 안되어서 한 다섯번은 다시 읽음, 이 문제도 비관적 잠금으로 해결 할 수 있는거 아닌지?)

일단 이 부분 넘어가고

낙관적 잠금은 우리가 직접 버전 관리를 하는것이다.

즉 테이블에 updateAt이나 version 같은 컬럼을 둔다.

고객이 업데이트 하면 updateAt이 최신 버전이 될것이다.

이때 운영자가 배송 상태 변경 할려고 할 떄  updateAt 값이 다르므로 업데이트에 실패한다. 

즉 이것을 한줄 요약 표현하자면 낙관적 잠금 방식은  변경한 데이터를 실제 DBMS에 반영하는 시점에 변경 가능 여부를 확인하는 방식이다.

그에 비해 비관적 잠금 방식은 동시에 접근하는것을 직렬화 하는 방식이다.

![Untitled (42).png](https://blog.kyb.pe.kr/api/v2/file/static/cb73d1cc-a7f5-4dbc-8246-9df422d5c041)

### 강제 버전 증가

애그리거트 안에는 애그리거트 루트 외에 다른 엔티티가 존재한다. 

근데 다른 엔티티만 업데이트 된다면 루트 애그리거트는 버전이 업데이트가 되지 않는다. 

그러나 이는 일관성이 깨진것이다. 

애그리거트의 구성 요소 중 일부 값이 바뀌면 논리적으로 애그리거트가 바뀐 것이다. 

이를 위해 JPA에서는 강제 버전 증가 기능을 제공한다. 

# 오프라인 선점 잠금

아틀라시안의 컨플루언스는 문서를 편집할 때 .

다른 사용자가 문서를 수정하고 있다고 안내 문구를 보여준다. 

이는 응용 프로그램 상에서 Lock를 구현한 형태로 읽어보면 재밌긴하나.

내용상으로 뇌절이라고 생각해서 생략함 궁금한 사람은 

page 263 참고

DDD 시작하기 정리 -5 애그리거트와 트랜잭션 관리

도메인 서비스에 대해 알아보자. 

# 개요
 
도메인 영역의 코드를 작성하다 보면. 한 애그리거트에서 기능을 구현할 수 없을 경우가 있다. 

대표적으로 결제 금액 계산 로직이다. 

- 상품 애그리거트: 구매하는 상품의 가격이 필요하다. 또한 상품에 따라 추가되는 배송비도 필요하다.
- 주문 애그리거트: 상품별로 구매 개수가 필요하다.
- 할인 쿠폰 애그리거트: 쿠폰별로 지정한 할인 금액이나 비율에 따라 주문 총 금액을 할인한다. 할인 쿠포을 조건에 따라 중복 사용할 수 있거나 지정한 상품 카테고리의 적용할 수 있다는 제약 조건이 있다면 할인 계산이 복잡해진다.
- 회원 애그리거트: 회원 등급에 따라 추가 할인이 가능하다.

이 경우 실제 결제 금액을 계산해야하는 주체는 어떤 애그리거트일까? 

생각해 볼 수 있는 방법은 주문 애그리거트가 필요한 데이터를 모두 가지도록 한 뒤 할인 계산 책임을 주문 애그리거트에 할당하는것이다. 

그러나 이는 잘못된 방식이다. 

예를 들어서 특별 감사 세일로 전품목에 대해 10% 할인 행사를 진행한다고 가정해보자.

이 할인 정책은 주문 애그리거트가 갖고 있는 구성요소와 상관 없음에도 불구하고, 결제금액을 계산해야하는 책임이 있는것이 주문 애그리거트라서 주문 애그리거트의 코드를 수정 해야한다. 

**이렇게 한 애그리거트에 넣기 애매한 도메인 기능을 억지로 특정 애그리거트에 구현하면 안된다.** 

위와 같이 억지로 구현하면 애그리거트의 자신의 책임 범위를 넘어서는 기능을 구현하기 때문에 

외부에 대한 의존이 높아지게 되며 코드를 복잡하게 만들어서 수정을 어렵게 만드는 요인이 된다. 

이런 문제를 해소 하는 패턴이 도메인 서비스 패턴이다. 

# 도메인 서비스

주로 다음 상황에서 도메인 서비스를 사용한다. 

- 계산 로직: 여러 애그리거트가 관여하는 계산 로직, 한 애그리거트에 넣기에는 다소 복잡한 계산 로직
- 외부 시스템 연동이 필요한 도메인 로직: 구현 하기 위해 타 시스템을 사용해야 하는 도메인 로직

도메인 서비스와 도메인 구성요소와 가장 큰 차이점은 도메인 구성요소( 엔티티, 밸류 )는 

상태 없이 로직만 구현한다는 점이다. 

![Untitled (35).png](https://blog.kyb.pe.kr/api/v2/file/static/cfabfaae-d11c-410c-9f30-fdca210f5465)

할인 계산 서비스를 사용하는 주체는 애그리거트가 될 수있고, 

응용 서비스가 될 수도 있다. 

### 애그리거트가 주체가 되는 경우

![Untitled (36).png](https://blog.kyb.pe.kr/api/v2/file/static/451f9a4a-0bf8-484f-b05f-cf91db9fbf4a)

애그리거트에 도메인 서비스를 전달하는 것은 응용 서비스의 책임이다. 

**주의 사항**

애그리거트 루트 엔티티에 도메인 서비스 DI 하지 말자. 

스프링 개발자라면 DI와 AOP를 이용해서 애그리거트에 도메인 서비스를 주입하고 싶을것이다. 

그러나 도메인 객체는 필드로 구성된 데이터와 메서드를 이용해서 개념적으로 하나인 모델을 표현한다.

모델의 데이터를 담는 필드는 모델에서 중요한 구성요소다. 그러나 도메인 서비스 필드는 데이터 자체와 관련이 없다. 

또 모든 애그리거트 루트에 도메인 서비스가 필요한 것도 아니다. 일부 기능만 필요로 한다. 

그렇기 때문에 애그리거트 루트에 도메인 서비스를 DI 하는것은 지양 해야한다. 

### 응용 서비스가 주체가 되는 경우

예를 들어서 계좌 이체 같은 기능이다. 

![Untitled (37).png](https://blog.kyb.pe.kr/api/v2/file/static/07073c70-e0e8-4246-b0fa-2d59a9712702)

이런식으로 도메인 서비스를 구현하고, 

응용 서비스에서 애그리거트를 구해서, 도메인 서비스를 호출한다. 

도메인 서비스는 응용 로직을 수행하지 않는다. ( 트랜잭션 처리는 응용 로직이므로, 도메인 서비스가 아니라 응용 서비스에서 처리해야한다)

나는 당연히 도메인 서비스라고 해서 위와 같이 응용 서비스가 주체가 되어서 

관련 애그리거트들 모아서, 도메인 서비스로 보내고, 도메인 서비스에서 해당 애그리거트들이 오케스트레이션 해서 기능을 구현 하고

응용 서비스에서 해당 기능을 영속화 하는 그런 구조로 생각한다.

위의 애그리거트가 주체가 되는 경우는 좀 내 생각에는 이상하다. 

일단 도메인 서비스 개념 자체가 여러 개의 애그리거트가 필요한건데, 

하나의 애그리거트가 주체가 된다면

다른 애그리거트까지 전부 하나의 애그리거트에서 로딩해야하지않는가? 이는 경계가 무너진거 아닌가?

형태 또한 이상하다. 저자가 왜 저런식으로 사용할 수 있다고 언질 했는지 이해가 되지 않는다. 

 

## 도메인과 외부 시스템 연동

이는 DIP로 구현한다. 

예를 들어서 설문 조사 시스템과 사용자 역할 관리 시스템이 분리 되어있다고 하자. 

설문 조사 시스템은 설문 조사를 생성할 때, 사용자가 생성 권한을 가진 역할인지 확인 해야한다. 

이때 인프라 영역에 설문 조사 시스템의 구현체를 구현하고.

도메인 영역에 사용자 도메인과 인프라 영역의 구현체를 의존하는 객체를 만든다.

![Untitled (38).png](https://blog.kyb.pe.kr/api/v2/file/static/75c72a0c-e11f-4616-83c6-15df8a95fecf)

SurveyPermissionChecker 인터페이스를 구현한 클래스는 인프라스트럭처 영역에 위치해 연동을 포함한 권한 검사 기능을 구현한다.

DDD 시작하기 정리 -6 도메인 서비스



응용 서비스와 표현 영역에 대한 주의사항 정리 합니다.

# 응용 서비스

응용 서비스는 요청한 기능을 수행 한다.

표현 영역 관점에서 본다면 응용 서비스는 도메인 영역과 표현 영역을 연결해 주는 창구 역할을 한다. 

응용 서비스의 기능의 전형적인 패턴으로 

- 요청 검증
- 도메인 준비
- 도메인 로직 실행
- 도메인 영속화
- 결과 리턴

위 리스트 순서대로 진행한다. 
 

```java

@Service
class SomeService {
 ...
 public Result doSometing(DomainRequest req){
   validate(req); // 요청 검증
   SomeDomain domain = SomeDomainRepository.findById(req.domainId); // 도메인 준비
  
   domain.doSometing(); // 도메인 로직 실행
   ...
   
   SomeDomainRepository.save(domain); // 도메인 영속화
   return result; // 결과 리턴 
 }
}

```

## 응용 서비스의 기능이 복잡하다면 의심하자!

응용 서비스의 기능이 복잡하다면 **해당 기능이 도메인 로직의 일부분을 구현할 가능성이 높다!**

```java
public void changePassword(String memberId, String oldPwd, String newPwd){

 Member member = ...
 
 if(newPwd.length() < 8){
   throw new BadPasswordException(); 
 }
 ...

}

```

위와 같이 패스워드가 최소 8이상의 길이를 가져야한다를 응용 서비스 기능에서 구현하고 있다. 

이렇게 하면 코드의 응집성이 떨어진다. 도메인 데이터와 그 데이터를 조작하는 로직이 한 영역에 위치 하지 않고 서로 다른 영역에 위치해서 도메인 **로직을 파악하는데 여러 영역을 분석해야한다.** 이는 영역을 나눔으로서 오히려 안좋아지는쪽으로 진행 된것이다. 

또한 도메인 로직을 특정 응용 서비스 기능에 구현함으로서 , 다른 응용 서비스의 기능에서 중복해서 구현할 가능성도 높아진다. 그것을 피하기 위해 서비스가 다른 서비스를 의존하는 형태가 되는데, 이는 코드를 점점 파악하기 어렵게 한다. 

(물론 서로 서비스가 연동 되어야할 경우가 생긴다. 대표적인 예로 회원가입한다면 이메일을 전송한다면

회원 가입 서비스 영역과 이메일 전송 서비스가 같이 오케스트레이션 되어야한다. 이때 정석적인 방법은 이벤트로 서로 연동 하는 방식이다) 

## 응용 서비스의 인터페이스와 클래스

저자의 주장은 다음과 같다. 

응용 서비스를 구현할 때 논쟁이 될 만한 것이 인터페이스가 필요한지이다. 

인터페이스가 필요한 경우는 구현 클래스가 여러 개인 경우 런타임에 구현 객체를 교체해야하는 경우 인터페이스를 유용하게 사용할 수 있다.

그러나 서비스 응용 계층은 위와 같은 경우가 거의 발생 하지 않는다. 

그래서 굳이 인터페이스를 구현할 필요가 없다. 

그러나 테스트 주도 개발을 한다면 인터페이스가 필요 할 수 있지만,

Mockito와 같은 테스트 도구를 사용하면 인터페이스가 굳이 필요 없다.

저자의 생각과 다른 내 생각은 

Mockito와 같은 목킹 도구를 사용하는것을 지양한다는 점이다. 

이유는 인터페이스를 구현해서 **가짜 객체를 만드는것 자체가 설계에 피드백을 주기 때문이다.**

만약 인터페이스를 구현하면서 가짜 객체를 만드는게 힘들다면, 

인터페이스 쪽에 문제가 있는지 확인 하는 피드백을 받을 수 있다.

그리고 가짜 객체를 직접 구현함으로서 오히려 목킹 된 난잡한 코드로 테스트에서 돌아가고 있는 것보다 더 이해 하기 쉬운 형태로 , 더 제어하기 쉬운 형태로 가짜객체를 이용할 수 있다. 

(파이썬으로 살펴보는 아키텍처에서 이 부분 다시 찾아서 내용 보완하기) 

## 응용 서비스 기능의 파라미터와 값 리턴

### 값 리턴

응용 서비스의 값 리턴에서 **기본적으로 도메인 객체를 반환 하지 않는다.**

표현 영역으로 도메인 객체가 존재 하게 된다면 코드의 응집성이 떨어진다. 

따라서 기본적으로 응용 서비스는 기본적으로 표현영역에서 필요한 데이터만 리턴 하도록 하는것이 응집도를 높이는 방법이다. 

### 파라미터

응용 서비스의 파라미터를 결정할 때 중요한 사항은 표현 영역과 관련된 타입을 사용하면 안된다는 점이다. 

![Untitled (33).png](https://blog.kyb.pe.kr/api/v2/file/static/e6ff5731-3c13-4774-9c95-9e2bd71c0289)

테스트 주도 관점에서 보자면 이렇게 표현 영역 관련된 타입을 의존하는 순간 

테스트가 어려워짐을 피드백 받을 수 있다. 

그 말은 다시 표현하면 응용 서비스가 표현 계층에 종속적으로 변한다.
 
그렇기에 표현 영역의 구현이 변경 되면 응용 서비스의 구현도 변경 된다. 

그러나 이는 큰 문제가 아니다 왜냐면 표현 영역의 구현이 변경 되는 경우는 적기 때문이다.

정말 큰 문제는 응용 서비스 계층에서 표현 영역의 역할 까지 대신 하는 상황이 발생 하기 쉽다.

![Untitled (34).png](https://blog.kyb.pe.kr/api/v2/file/static/abff7a4c-9d2e-4192-b838-9e34660986c2)

HttpSession이나 쿠키는 표현 영역의 상태를 해당하는데, 이 상태를 응용 서비스에서 변경해버리면

표현 영역의 코드만으로 표현 영역이 상태가 어떻게 되는지 추적하기 어려워진다.

즉 표현 영역의 응집도가 깨진다. 

# 표현 영역

표현 영역의 책임은 다음과 같다. 

- 사용자가 시스템을 사용할 수 있는 흐름(화면)을 제공하고 제어한다.
- 사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공한다.
- 사용자의 세션을 관리한다.

## 값 검증

값 검증은 표현 영역과 응용 서비스 두 곳에서 모두 수행 할 수 있다. 

원치적으로 모든 값에 대한 검증은 응용 서비스에서 처리한다. 

기본적인 오래된 국룰은 

- 표현 영역: 필수 값, 값의 형식, 범위 등을 검증한다.
- 응용 서비스: 데이터의 존재 유무와 같은 논리적 오류를 검증한다.

저자의 경우 예전에서는 표현영역에서 필수값 검증하고, 응용 서비스에서 필수 값 검증과 논리적인 검증을 했다고 하는데, 요즘은 가능하면 응용 서비스에서 필수 값 검증과 논리적인 검증을 한다고 한다.

이렇게 하면 서비스 계층의 완성도가 높아지는 이점이 있다고 한다. 

나 역시도 서비스 계층에서 전부 구현하는게 좋을듯 하다. 

필수 값, 값의 형식, 값의 범위 등등 도메인 계층에서 검증하고.

데이터 베이스로 확인 해야하는 논리적인 오류를 레포지터리에서 검증하고

전부 서비스 계층에서 취합해서 던지는게 깔끔 한 것 같다. 

## 권한 검사

표현 영역, 응용 서비스, 도메인 영역 모든 계층에서 권한 검사를 할 수 있다. 

표현영역에서 권한 검사는 기본적으로 인증된 사용자 확인이다. 

대표적인 예가 회원 정보 변경이다. 회원 정보 변경과 관련된 **URL은 인증된 사용자만 접근**할 수 있다. 

인증된 사용자가 아니라면 로그인 화면으로 리다이렉트 한다. 

URL 접근 제어만으로 권한을 제한 못한다면 응용 서비스 혹은 도메인 영역에서 권한 검사를 해야 한다.

DDD 시작하기 정리 -4 응용서비스와 표현영역

리포지터리 패턴에 대해 알아봅시다.  

# 개요

애그리거트를 어떤 ORM 사용하여 저장할지에 따라 리포지터리의 구현은 천차만별로 달라진다. 

일단 책에서는 JAVA로 JPA 이용해서 구현한다. 

(실제로 내가 구현할것은 Python의 **SQLAlchemy**로 구현할 것)

리포지터리는 기본적으로 두 가지 기능을 구현해야한다.

1. id로 애그리거트 조회하기
2. 애그리거트 저장하기 


## 매핑 구현

![Untitled (31).png](https://blog.kyb.pe.kr/api/v2/file/static/a62f4bff-399f-4f7b-bec3-e71f6c1c3839)


책에선 위와 같이 매핑한다.  한마디로 하나의 테이블로 매핑 한다. 

책에서는 너무 JPA 관련 기술 설명 밖에 없어서 스킵한다. 

## 별도 테이블에 저장하는 밸류 매핑

애그리거트에서 루트 엔티티 뺸 나머지 구성 요소들은 대부분 밸류이다.

루트 엔티티외에 또 다른 엔티티가 있다면 진짜 엔티티인가 의심해봐야한다. 

OrderLine의 경우 별도 테이블에 저장하지만, OrderLine 자체는 엔티티가 아닌 밸류이다. 

밸류가 아니라 엔티티가 확실하다면, 해당 엔티티가 다른 애그리거트 아닌지 확인 해야한다. 

특히 자신만의 독자적인 라이플 사이클을 갖는다면, 구분되는 애그리거트 가능성이 높다. 

예를 들어서 상품과 상품 리뷰의 관계이다. 

Product와 Review는 함께 생성 되지 않고, 함께 변경 되지 않는다. 

게다가 변경 주체도 다르다. 따라서 서로 다른 애그리거트이다. 

## 매핑 논란

![Untitled (32).png](https://blog.kyb.pe.kr/api/v2/file/static/58f5c6ce-356b-4115-8b50-b3203ecb5231)


매핑 한다면 모델이 위에 처럼 JPA 어노테이션으로 도배된다.

**이는 도메인 모델이 인프라스트럭처에 종속 된다는것을 의미한다.**

원래 DDD 에서 도메인모델은 인프라스트럭처에 종속되면 안된다. 

이 책 저자도 역시 DIP를 위반한다고 인정한다.

그러나 DIP를 적용하는 주된 이유는 저수준 구현이 변경 되더라도 고수준이 영향을 받지 않도록하기 위함인데. 리포지터리와 도메인 모델의 구현 기술은 거의 변하지 않는다. 

저자는 JPA로 구현한 리포지터리 구현 기술을 마이바티스나 다른 기술로 변경한 적이 없고, RDBMS를 사용하다 몽고 DB로 변경한 적도 없다. 

이렇게 변경이 거의 없는 부분에 미리 대비하는것은 과하다고 생각한다고 타협했다고 한다. 

그러나 내 생각은 다르다.

이렇게 도메인 모델이 JPA 세부사항에 종속됨으로서 코드가 상당히 복잡해보인다. 

그렇기 때문에 점점 변경하는것이 어려워질것이다. 사람이 실수할 확률도 높다.

예를 들어서 JPA 설정 잘못 하면 속성 삭제했다고, 데이터베이스 테이블 속성 삭제되지 않는가?

변경에 대비해서 분리하는것보다 각각의 도메인 모델과 데이터베이스(영속)계층을 분리함으로서

서로 확장 가능하게 명시적으로 선언한다면, 한쪽이 달라졌을 때 바로 에러 메시지 뜨면서 훨씬 더 안전한 환경이 될 것이다. 

SQLAlchemy는 다음과 같이 가능하다. 

```python
# model.py

class OrderLine(models.Model):
	id: int
	product_id:str
	price:float
  quantity: int
  order_id: int
  def get_sum_price(self) -> float:
			return self.price * self.quantity

class Order(models.Model):
	id: int
  orderLines: List[OrderLine]

-# orm.py
from sqlalchemy.orm import mapper, relationship

import model # 모델에 종속 ( 높은 추상화에 의존) DIP

metadata = MetaData()

order_lines = Table("order_lines',metadata,
				Column("id", Integer, primary_key=True, autoincrement=True),
				Column("order_id", ForeignKey("order.id")),
		...)

orders = Table("order",metadata,
		Column("id", Integer, primary_key=True, autoincrement=True),
               ...)

def start_mappers():
    logger.info("Starting mappers")
    lines_mapper = mapper(model.OrderLine, order_lines)
    order_mapper = mapper(
        model.Order,
        orders,
        properties={
            "orderLines": relationship(
                lines_mapper,
                collection_class=list,
            )
        },
    )
```

DDD 시작하기 정리 -3 리포지터리

 DDD 핵심 패턴인 엔티티와 밸류에 대해 알아봅시다. 

## 엔터티와 밸류

![Untitled (14).png](https://blog.kyb.pe.kr/api/v2/file/static/8d8cfabe-5b0f-4853-b71a-7f5ec531b0cf)

도출한 모델은 크게 엔티티와 밸류로 구분할 수 있다. 

**엔티티와 밸류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기** 때문에 이 둘의 차이를 명확하게 이해하는것은 도메인을 구현 하는데 있어서 중요하다. 

### 엔티티

식별자를 가진다. 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 

엔티티를 생성하고 다른 속성이 바꾸고 삭제할 때까지 식별자는 유지 된다. 

### 밸류타입

밸류타입은 개념적으로 완전한 하나를 표현할 때 사용한다. 

예를 들어서 배송 수하인 다음과 같이 표현할 수 있다. 

```java
public class Receiver {
	private String name;
	private String phoneNumber;
  private String address;
  private String zipCode;
  ...
}
```

또한 밸류타입은 기본적으로 불변이 권장 된다. (엔티티는 식별자를 가지지만, 밸류타입은 모든 값이 하나로서 식별자라고 보는것이다) 

### 도메인 엔티티와 DB 엔티티 비교

DB 모델의 엔티티와 도메인 계층의 엔티티는 서로 굉장히 비슷하지만 다르다. 

이 두 모델의 가장 큰 차이점은 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 제공한다는 점이다. 

![Untitled (15).png](https://blog.kyb.pe.kr/api/v2/file/static/c3abd8bf-0269-4195-a5e1-4a3e1d1a775c)

도메인 엔티티는 기능을 구현하고, 기능 구현을 캡슐화해서 데이터가 임의로 변경 되는것을 막는다. 

또 다른점은 도메인 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해서 표현할 수 있다. 

그에 비해 데이터베이스 엔티티는 밸류 타입을 표현하기 어렵다. 

![Untitled (16).png](https://blog.kyb.pe.kr/api/v2/file/static/003f540a-3c35-4c71-887b-9f7c33ca1bec)

# 애그리거트

도메인이 확장 될 수록 도메인 모델도 많아지면서 엔티티와 밸류가 폭발적으로 늘어난다.

즉 점점 관리하기 어려워진다. 


![Untitled (17).png](https://blog.kyb.pe.kr/api/v2/file/static/a0e9a1a3-f999-46cd-a1b9-e8ad334bc2cf)

애그리거트는 관련 객체를 하나로 묶는 군집이다. 

개인적으로 디자인패턴 중에 퍼사드 패턴과 많이 비슷한것 같다. 

## 애그리거트의 의미

- 관련 객체를 하나의 군으로 묶음으로서 도메인 모델간의 관계 파악이 쉬워진다.
- 모델간의 일관성을 관리하는 기준이 된다.
    
    관련된 모델을 하나로 모았기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다. 주문 애그리거트를 만들려면 Order, OrderLine, Orderer와 같은 관련 객체를 함께 생성한다. 
    
- 경계를 만들어 도메인을 더욱 명확하게 한다.
    
    ![Untitled (18).png](https://blog.kyb.pe.kr/api/v2/file/static/a8040d31-0403-4b58-a036-abf38656ea6f)
    
    한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 애그리거트는 독립된 객체군이며
    
    각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다. 
    
    예를 들어서 주문 애그리거트는 회원 비밀변경 하거나 상품의 가격을 변경 하지 않는다. 
    

## 애그리거트 루트

애그리거트 전체를 관리할 주체가 필요하다. 

**이 책임을 지는 것이 바로 애그리거트 루트 엔티티이다.**

애그리거트에 속한 객체는 애그리거트 루트 엔티티에 직접 또는 간접적으로 속하게 된다. 

![Untitled (19).png](https://blog.kyb.pe.kr/api/v2/file/static/be9a4a5e-52aa-422d-a4bf-446fc0ae4136)

**애그리거트 루트 엔티티의 책임은 애그리거트의 일관성을 유지하는것이다.** 

일관성을 유지하기 위해서는 외부에서 애그리거트의 내부 객체를 접근하거나 조작할 수 없게 해야한다. 

애그리거트 루트를 통해서만 도메인 로직을 구현하고 도메인 로직을 실행 해야 한다. 

### 애그리거트 루트의 기능 구현

애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다. 

![Untitled (20).png](https://blog.kyb.pe.kr/api/v2/file/static/81ed6026-6cf8-4675-bb4b-2419e8872ec0)

### 트랜잭션 범위

트랜잭션 범위는 작을 수록 좋다. 

한 트랙잭션이 한 개 테이블을 수정하는것과 세 개의 테이블을 수정하는것을 비교하면 성능 차이가 발생한다. 한 개 테이블을 수정하면 트랜잭션 충돌을 막기 위해서 잠그는 대상이 한 개 테이블의 한 행으로 한정 되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아 진다. 

잠금 대상이 많아진다는것은 그만큼 동시에 처리할 수 있는 트랜잭션의 개수가 줄어든다는 의미이고, 이것은 전체적인 성능을 낮춘다. 

원칙적으로 하나의 애그리거트 하나의 트랜잭션이다. 

그런데 말처럼 쉽지가 않다. 

예를 들어서 주문 배송정보를 바꿀 때, 마찬가지로 회원의 주소도 변경 되길 원하는 기능을 많이 봤을 것이다. 

![Untitled (21).png](https://blog.kyb.pe.kr/api/v2/file/static/92013167-be39-48c2-8590-e77ce8551f15)

이런식으로 응용계층에서 각각의 애그리거트 가져와서 오케스트레이션 하고 있다. 

그렇지만 오케스트레이션 하는 과정에서  하나의 트랜잭션으로 두 개의 애그리거트를 접근 한다. 

이런 트랜잭션의 범위 문제 , 애그리거트 간의 연동 문제를 해결하기 위해서 도메인 이벤트라는

이벤트 중심 개발로 이벤트로 해결한다.

## 리포지터리와 애그리거트

애그리거트는 개념상 완전한 한 개의 도메인 모델을 표현하므로, 객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다. Order와 OrderLine을 물리적으로 각각 별도의 DB 테이블에 저장한다고 해서 

Order와 OrderLine을 위한 리포지터리를 각각 만들지 않는다. 

리포지터리에 관련된 내용은 하나의 챕터로 밑에서 정리. 

## 애그리거트 참조 문제

한 객체가 다른 객체 참조하듯이 애그리거트 루트가 다른 애그리거트 루트를 참조할 수 있다. 

![Untitled (22).png](https://blog.kyb.pe.kr/api/v2/file/static/7a1e3705-eb1c-4d3b-b232-30ea7c576bd9)

이는 잘못된 패턴이다.

기껏 애그리거트라는 경계를 만들었는데, 이를 스스로 없애는 짓이다. 

![Untitled (23).png](https://blog.kyb.pe.kr/api/v2/file/static/a74f433c-677d-402a-9ba5-983487e945b2)

이런식으로 ID 참조로 우회한다. 

그리고 정작 정말 Member가 필요하다면 
![Untitled (24).png](https://blog.kyb.pe.kr/api/v2/file/static/57f97bf8-2c1f-4b29-8e31-3e94b77bd0c0)

ID 참조로 응용 계층에서 조회한다. 

### ID를 참조한 조회 성능

Id를 조회하기  N+1 문제가 발생하기 쉽다. 

![Untitled (25).png](https://blog.kyb.pe.kr/api/v2/file/static/fd4b0db8-9e08-4821-9c23-59f8d69f274f)

이처럼 하나의 주문에 여러 번의 프로덕트 조회하면서 N+1 문제가 발생한다. 

**나의 해결 방식** 

나는 위와 문제가 생기면 product id를 모아서 in절 Query로 조회한다

 N+1 문제가 1+1 문제로 바뀐다. 그러나 in절 Query는 인덱스를 수직 탐색을 * n 하는 쿼리로

인덱스 깊이가 깊다면 ( 데이터가 많거나 ) in절에 사용된 id 리스트가 길수록 성능이 떨어진다. 

**책 저자 해결 방식**

![Untitled (26).png](https://blog.kyb.pe.kr/api/v2/file/static/9d90abcd-2365-4c6e-9b31-1a730883f5f2)

이런식으로 JPQL로 조인 하는 조회 전용 쿼리를 만든다. 
  

## 애그리거트를 팩토리로 사용하기

고객이 특정 상점을 여러 차례 신고해서 해당 상점이 더 이상 물건을 등록하지 못하도록 차단한 상태라고 해보자. 상품 등록 기능을 구현한 응용 서비스는 다음과 같이 상점 계정이 차단 상태가 아닌 경우에만 상품을 생성하도록 구현할 수 있을것이다. 

 
![Untitled (27).png](https://blog.kyb.pe.kr/api/v2/file/static/23fd0453-4a77-47dc-8930-dfc6d5989dfb)


이 코드는 나쁘다. 

중요한 도메인 로직 구현이 응용계층에 노출 되었다.

응용 계층 책임은 서버의 1. 서버의 유스케이스의 구현 2. 여러 요소간의 오케스트레이션 이지 

도메인 로직 구현이 아니다.

따라서 이런식으로 하는것이 좋다. 

![Untitled (28).png](https://blog.kyb.pe.kr/api/v2/file/static/0527d1e5-1ec3-450d-ab9d-00b4540d0efa)

스토어 애그리거트가 프로덕트 애그리거트를 생성한다 ( 팩토리 패턴 )

팩토리 역할을 하면서 중요한 도메인 로직을 구현하고 있다. 

물론 위와 같이 말고, 도메인 서비스( 애그리거트간의 오케스트레이션 ) 만들수도 있다. 

아무튼 서비스 계층은 다음과 같이 변한다. 

![Untitled (29).png](https://blog.kyb.pe.kr/api/v2/file/static/5307cf98-5267-4b4a-844b-e3b3c896a81b)

이런식으로 애그리거트를 다른 애그리거트를 생성하는 (팩토리) 구현하면 

도메인 로직이 도메인 계층에 존재하도록 일관성을 지키는것이 편해진다. 

다만 아쉬운점이 있다면 

스토어가 프로덕트를 생성 함으로서 스토어가 프로덕트에 대해 많이 알아야 하는 점이다. 

이것은 다음과 같이 해결 할 수 있다. 

![Untitled (30).png](https://blog.kyb.pe.kr/api/v2/file/static/ecd914cb-3673-460f-99db-3ef7d1acd6a5)

차단 상태의 스토어는 제품을 등록할 수 없다는 도메인 로직을 도메인 모델에 위치하도록 일관성을 지키고.

프로덕트 팩토리로 프로덕트 애그리거트에 대해 상세히 알지 않아도 되도록 구현 되었다.

DDD 시작하기 정리 -2  엔티티, 밸류, 애그리거트

개요.

 # 0. DIP

DDD를 시작하기 전에 배경 지식으로 DIP에 대해서 알아보자. 

표현, 응용, 도메인, 인프라스트럭처는 아키텍처를 설계할 때 출현하는 전형적인 네 가지 영역이다.

![Untitled.png](https://blog.kyb.pe.kr/api/v2/file/static/1445d099-13d9-4cbd-aba5-70bf3860046b)

응용 영역은 시스템이 사용자에게 제공해야할 기능을 구현하는데, 

예를 들어서 이커머스를 예로 들자면 

 주문 등록, 주문 취소, 상품 상세 조회와 같은 기능 구현을 예를 들 수 있다.


### 응용 영역

**응용 서비스는 로직을 직접 수행하지않고, 도메인 모델에 로직 수행을 위임한다.**

![Untitled (1).png](https://blog.kyb.pe.kr/api/v2/file/static/cf502ded-2785-4abd-88d6-69c6ca941c61)

도메인 모델은 도메인의 핵심 로직을 구현한다.



### 인프라 스트럭처

도메인 영역, 응용 영역, 표현 영역은 구현 기술을 사용한 코드를 직접 만들지 않는다. 

대신 인프라스트럭처 영역에서 제공하는 기능을 사용해서 필요한 기능을 개발한다. 

예를 들어서 인프라스트럭처 영역의 DB 모듈을 사용해서 데이터를 읽어온다.


## 계층형 아키텍처

![Untitled (2).png](https://blog.kyb.pe.kr/api/v2/file/static/cc0b5a1d-dce1-4081-9274-48151d51ba16)

계층별로 단방향 의존 하는 아키텍처이다.

표현은 응용에 의존하고, 응용은 도메인에 의존하며, 도메인은 인프라스트럭처에 의존하는 구조인데.

편의상

![Untitled (3).png](https://blog.kyb.pe.kr/api/v2/file/static/22fd04d5-96c4-4e9a-a834-61e99fd37808)

이런식으로 유연하게 가져간다. 

**그러나 이는 잘못된 구조이다.**

**응용계층과 도메인 계층이 인프라스트럭처에 종속된다.** 

아래의 코드로 확인해보자. 

![Untitled (4).png](https://blog.kyb.pe.kr/api/v2/file/static/8387d4eb-97e8-4d46-a5e3-5e1083eb4112)

인프라스트럭처에 의존하면 테스트 어려움과 기능 확장의 어려움이라는 두 가지 문제가 발생한다. 

이를 해결 하기위해서 DIP를 사용한다.


## DIP

![Untitled (6).png](https://blog.kyb.pe.kr/api/v2/file/static/72fe7816-d632-4cdf-8038-f04e727fcfd4)

가격할인을 계산할려면 왼쪽과 같이 고객 정보를 구해야하고, 구한 고객 정보와 주문 정보를 이용해서 룰을 실행 해야한다. 

응용계층( CalculateDiscountService )가 제대로 작동할려면 저수준 모듈인 JPA와 Drools를 사용(의존) 해야한다. 이는 구현 변경과 테스트가 어렵다는 문제가 발생한다. 

그렇다면 이를 어떻게 해결 할 수 있을까?

정답은 추상화 계층을 하나 더 추가 하는 것이다. 

 ![Untitled (7).png](https://blog.kyb.pe.kr/api/v2/file/static/d816cff0-3864-4bf1-8f50-fede62cf9985)

CalculateDiscountService 입장에서는 룰적용을 Drools로 구현했는지 관심없다. 

고객 정보와 구매정보를 룰에 적용해서 할인 금액을 구한다느것이 중요하다. 

![Untitled (8).png](https://blog.kyb.pe.kr/api/v2/file/static/0074b061-760f-4123-8a99-d06684715f73)

이렇게 추상화 계층을 만들어서 CalculateDiscountService가 이를 의존하게 만든다. 

이처럼  DIP 적용하면 저수준 모듈이 고수준 모듈에 의존하게 된다. 

고수준 모듈이 저수준 모듈을 사용하면 고수준 모듈이 저수준 모듈에 의존 해야 하는데, 

반대로 저수준 모듈이 고수준 모듈을 의존한다고해서 의존 역전 원칙 ( DIP )라 부른다. 

## DIP 주의 사항
 
단순히 잘못 생각하면 ISP로 이해할 수 있다. 

그러나 DIP은 ISP가 아니다. 

<ISP 관점에서> 

![Untitled (9).png](https://blog.kyb.pe.kr/api/v2/file/static/310b302a-29a5-46b2-87dc-a9ee9b6eea09)

이 구조에서 도메인 영역은 구현 기술을 다루는 인프라스트럭처 영역에 의존하고 있다. 

여전히 고수준 모듈이 저수준 모듈에 의존하고 있는것이다. 

RuleEngine 인터페이스는 룰엔진이라는 저수준 모듈 관점에서 도출한것이다. 

DIP 를 적용할 떄 하위 기능을 추상화한 인터페이스는 고수준 모듈에서 도출한다.

CalculateDiscountService 입장에서 봤을 때 할인 금액을 구하기 위해 룰 엔진을 사용하는지 직접 연산하는지 중요하지 않다. **단지 할인 금액을 계산한다는것이 중요하다.**


![Untitled (10).png](https://blog.kyb.pe.kr/api/v2/file/static/9550a438-9e1f-4709-95b5-e2bf6d0861ac)


## DIP와 아키텍처

![Untitled (11).png](https://blog.kyb.pe.kr/api/v2/file/static/d6e577e1-0b1c-431f-9652-32a4b7f973a1)

위와 같은 계층형 아키텍처를 다음과 같이 DIP 적용 한다. 

![Untitled (13).png](https://blog.kyb.pe.kr/api/v2/file/static/436aa6e2-9b20-409f-bab0-3a5e2c9d51ac)

인프라스트럭처는 저수준 모듈이고, 나머지 응용과 도메인 영역은 고수준 모듈이다. 

따라서 계층형 구조에서 인프라스트럭처는 응용과 도메인 영역을 의존하는 구조가 된다. 

# DDD 시작하기

도메인 주도 개발이란?

우리가 만드는 소프트웨어가 복잡해지는 이유는 도메인이 복잡 하기 떄문이다.

**우리는 도메인을 올바르게 표현하고 관리할 방법이 필요하다.** 

도메인 주도 개발은 도메인을 올바르게 표현하고 관리하는것이 좋은 설계라고 여기며

끊임 없이 더 나은 도메인 모델을 추출하기 위한 개발 방식이다. 

## 도메인 모델 도출

아무리 뛰어난 개발자라도 도메인에 이해 없이 코딩을 시작할 수없다.

기획서, 유스케이스, 사용자 스토리와 같이 요구사항과 관련자와의 대화를 통해 도메인을 이해하는것이 필수적이다. 

도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성 요소, 규칙, 기능을 찾는것이다. 

그 첫번째로 요구사항 분석에서 출발한다.

- 최소 한 종류 이상의 상품을 주문해야한다.
- 한 상품을 한 개 이상 주문할 수 있다.
- 총 주문 금액은 각 상품의 구매 가격 합을 모두 더한 금액이다.
- 각 상품의 구매 가격의 합은 상품 가격에 구매 개수를 곱한 값이다.
- 주문 할 때 배송지 정보를 반드시 지정해야한다.
- 배송지 정보는 받는사람 이름, 전화번호, 주소로 구성된다.
- 출고를 하면 배송지를 변경할 수 없다.
- 출고 전에 주문을 취소할 수 있다.
- 고객이 결제를 완료하기 전에는 상품을 준비하지 않는다.

정리하자면 배송지 정보 변경하기,  출고 상태 변경하기, 주문 취소하기, 결제 완료하기 기능을 제공한다는것이다. 

## 도메인 모델 패턴 예시.

만약 도메인 규칙이 배송지 변경은 주문 상태가 제품의 출고전 혹은 대금지불 이전에만 

가능하다는 규칙 있다면 아래와 같이 도메인 모델로 표현할 수 있다. 

```java

public class Order {
  private OrderState state;
	private ShippingInfo shippingInfo;

  private boolean isShippingChangeable(){
      return state == OrderState.PAYMENT_WAITING || 
              state == OrderState.PREPARING;	  
   }
  
  public void ChangeShippingInfo(ShippingInfo newShipping){
     if(!isShippingChangeable()){
		  throw new IllegalStateException("cant change shipping")	
     }
     this.shippingInfo = newShipping
  }  
}
```

도메인 계층은 이렇게 도메인의 핵심 규칙을 구현합니다. 

그리고 위와 같이 이런 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 **도메인 모델 패턴** 입니다.

이러한 패턴을 사용함으로서 도메인 규칙이 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야할떄 다른 계층에 영향을 덜 주고 확장이 가능해진다. 

이런식으로 도출된 나머지 기능들을 구현해야한다.( 생략 )

## 도메인 계층 구성 요소

- 엔티티와 밸류
    - 엔티티:  고유의 식별자를 갖는 객체로 도메인의 고유한 개념을 표현한다 ( 주문, 회원, 상품 ..)
    - 밸류: 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나의 값을 표현할 때 사용 (배송지,금액)
- 애그리거트
    
    연관된 엔티티와 밸류 자체를 개념적으로 하나로 묶는다. 
    
    예를 들어서 Order  엔티티 OrderLine 밸류, Orderer 밸류 객체를 **주문** 애그리거트로 묶을 수 있다.
    
- 리포지토리
    
    도메인 모델의 영속성을 처리한다.  
    
- 도메인 서비스
    
    특정 엔티티에 속하지 않는 도메인 로직을 제공한다. 할인 금액 계산은 상품, 쿠폰 회원 등급 구매 금액등 다양한 조건에 의거해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.




DDD 시작하기 정리 -1 개요

유틸리티 컨테이너를 빌드 컨테이너를 이용하고, 도커에 새롭게 추가된 멀티 스테이지로 대해 알아봅시다.  


# 빌드 컨테이너

빌드는 배포에서 기본적으로 처음으로 시작 되는 단계입니다. 

예를 들어서 Go 언어 같은 경우 코드를 빌드하여 실행 파일로 만드는 과정이 필요하고

React와 같은 프론트엔드 프로젝트들은 기본적으로 배포시에는 정적파일로 배포를 해야합니다. 

이때 두가지 방식으로 빌드 컨테이너를 구축했는데

첫째는 빌드 과정까지 하나의 Dockerfile로 작성하는 방식

둘째는 유틸 컨테이너로서 빌드 컨테이너를 만들고, 빌드 결과물을 복사한 결과물을 이미지화 시키는 작업이였습니다.

첫쨰의 과정은 이미지가 커지는 단점이 있었습니다. 

둘쨰는 이미지가 커지는 이유는 실제로 빌드환경을 구축하는 이미지의 용량이 배포 이미지 레이어에 포함 되기 때문에, 배포 결과물만 이미지화 시키는 작업으로 발전한 것입니다

하지만 요새는 첫째 과정과 둘쨰 과정을 모두 통합한 멀티 스테이지 방식을 사용 합니다. 

# 멀티 스테이지

멀티 스테이지 빌드는 

```docker
# `python-base` sets up all our shared environment variables
**FROM python:3.8 as python-poetry-base**
# Default to the latest version of Poetry
ARG POETRY_VERSION="1.1.7"

ENV POETRY_VERSION=${POETRY_VERSION}
ENV POETRY_HOME="/opt/poetry"
ENV POETRY_VIRTUALENVS_IN_PROJECT=true
ENV POETRY_NO_INTERACTION=1

ENV PATH="$POETRY_HOME/bin:$PATH"

###############################################################################
# POETRY BUILDER IMAGE - Installs Poetry and dependencies
###############################################################################
**FROM python-poetry-base AS python-poetry-builder**
RUN apt-get update && apt-get install --no-install-recommends --assume-yes curl
# Install Poetry via the official installer: https://python-poetry.org/docs/master/#installing-with-the-official-installer
# This script respects $POETRY_VERSION & $POETRY_HOME
RUN curl -sSL https://install.python-poetry.org | python3 -

###############################################################################
# POETRY RUNTIME IMAGE - Copies the poetry installation into a smaller image
###############################################################################
**FROM python-poetry-base AS python-poetry**
COPY --from=python-poetry-builder $POETRY_HOME $POETRY_HOME

###############################################################################
# dev
###############################################################################
**FROM python-poetry as dev**

WORKDIR /media_collector
COPY pyproject.toml .
COPY poetry.lock .

RUN poetry install

COPY . .

CMD ["/bin/bash"]

###############################################################################
# product
###############################################################################
**FROM python-poetry as prod**

WORKDIR /media_collector
COPY pyproject.toml .
COPY poetry.lock .

RUN poetry install

COPY . .

CMD ["/bin/bash"]
```

이처럼 여러개의 FROM절이 있는것을 볼 수 있는데. 이게 멀티 스테이지 빌드입니다. 

**스테이지는 서로 결과를 복사할 수 있습니다.** 

위에서 아래로 단계별로 모든 스테이지를 거쳐 현재 Dockerfile을 빌드 할 수 있습니다. 

또는 개별 스테이지를 선택해서 빌드할 수 있습니다. 

위 Dockerfile 예제로 본다면 poetry 라는 파이썬 패키지 매니저를 설치하는것을 볼 수 있습니다. 

이 패키지 매니저 빌드 하기 위해서 **python-poetry-base**  이미지를 사용해서 

아래와 같이 빌드를 해줍니다. 

```docker
**FROM python-poetry-base AS python-poetry-builder**
RUN apt-get update && apt-get install --no-install-recommends --assume-yes curl
# Install Poetry via the official installer: https://python-poetry.org/docs/master/#installing-with-the-official-installer
# This script respects $POETRY_VERSION & $POETRY_HOME
RUN curl -sSL https://install.python-poetry.org | python3 -
```

이렇게 빌드를 하면 $POETRY_HOME에 poetry 바이너리 파일이 생성 되는데 

그런 결과물만 아래와 같이 **COPY --from=** 이용해서 가지고 옵니다. 

```docker
**FROM python-poetry-base AS python-poetry**
COPY --from=python-poetry-builder $POETRY_HOME $POETRY_HOME
```

이제 **python-poetry 이미지** 굉장히 가벼운 상태로 딱 필요한 바이너리 실행 파일만 가지게 되므로 굉장히 가벼운 이미지가 됩니다.

Docker 기초 -6 도커 빌드 컨테이너 & 멀티 스테이지 

 유틸리티 컨테이너에 대해 알아봅시다. 

# 개요

기본적으로 Docker 애플리케이션의 실행 하는 환경과 + 코드가 합쳐진 구조입니다.

그러나 이러한 구조가 아닌 다른 용도로도 컨테이너를 사용할 수 있는데.

그것을 그냥 업계에서는 유틸리티 컨테이너라고 부릅니다. ( 비공식 )

이 유틸리티 컨테이너를 이용하기 위해서는 지금까지 사용 한적이 없는 명령어를 써야합니다. 

이것에 대해 알아봅시다.

NodeJS 예를 들어봅시다. 

패키지를 설치를 해야 package.json 업데이트가 됩니다.

그러나 패키지를 설치할려면 Node 환경이 필요합니다.

이는 호스트 컴퓨터에 노드를 깔아야된다는것을 의미합니다. 

이때 호스트 환경에 Node를 설치하지 않고 컨테이너로 NodeJS 환경을 설정하고 

package.json 파일을 업데이트 하는것입니다. 

```docker
docker run -it -d node:14-alpine 
```

위와 같이 실행하면 -d 모드로 백그라운드에서 실행 되지만 -it 입력을 기다리는 상태가 되어서 컨테이너가 바로 실행이 끝나지 않습니다. 

```docker
docker exec -it CONTAINER npm init
```

위와 같이 명령어를 선언하면 exec 명령어에 의해 npm init 명령어를 -it 모드로 실행 할 수 있습니다. 

아니면 다음과 같이 명령어를 써도 됩니다. 

```docker
docker run -it -d node:14-alpine npm init
```

이러면 node:14의 CMD 명령어를 npm init로 대체합니다. 

이제는 Dockerfile로 이러한 유틸 컨테이너를 정의 해봅시다. 

```docker
FROM node:14-alpine

WORKDIR /app

ENTRYPOINT ["npm"]
```

ENTRYPOINT 명령어는 docker run 이미지 이름 뒤에 명령으로 덮어쓰여집니다.

```docker
docker run -it -d IMAGE npm init
위의 명령어를 아래의 명령어처럼 사용할 수 있습니다. 
docker run -it -d IMAGE init
```

도커 컴포즈 확장

컴포즈에 해당 컨테이너를 서비스에 등록해서 사용할 수도 있습니다. 

예를 들어서 

```yaml
version: 3.8
services:
	npm:
		build: ./
		stdin_open: true
		tty: true
		volumes:
			- ./:/app
```

이때 docker-compose up 명령어를 사용하면 안됩니다.

이유는 up 명령어는 서비스를 불러오는 명령어로

 docker-compose up npm 하면 npm 서비스 가져오지만 뒤에 명령어를 붙힐수가 없습니다.

이유는  docker-compose up 서비스명1 서비스명2 .. 이런식으로 서비스들을 불러오는 명령어가 up 이라서 특정 컨테이너(서비스)에 명령어를 붙힐 수가 없습니다. 

이때 docker-compose run npm “명령어” 쓴다면 해당 서비스만 실행하여 명령어를 붙혀서 실행 시킬 수 있습니다. 근데 유의할 점은 docker-compose run은 자동으로 컨테이너가 삭제되지 않기 때문에 —rm 옵션을 줘야합니다.