잡소리3

어플리케이션 계층이 인프라를 의존하는 경우

• 구현을 교체하기 어렵다
• 응용 서비스나 도메인 로직 테스트가 어렵다. (인프라 없이 테스트하기 까다롭다. 결과가 다르게 나올 수 있다.)

왜 이런 문제가 발생할까? 다른 레벨(고수준, 저수준)이 섞여있기 때문이다.

• 영화 예매하기 (고수준)
• JPA로 영속성 객체 보관하기 (저수준)
• DB에 SQL 날리기(저저수준)

저수준이 바뀌었는데 고수준에 영향이 간다. 구체화에 의존하고 있다.

 

💭 해결책 DIP. 고수준의 입장에서 저수준을 추상화하라.

 

저수준(JavaMailEmailNotifier)를 고수준(EmailNotifier)의 인터페이스로 추상화하였다. 의존을 뒤집었다.

사실 저수준의 존재유무와 상관없이 단독으로 고수준을 만들 수 있다. DIP를 통해서

그런데 추상화할 때 많이 실수하는 부분이 있다.

'추상화'를 하라고 하니 단순히 인터페이스를 올리고, High-Class의 이름을 뽑아서 사용하는 구조

사실 이는 제일 처음 봤던 구조와 다른게 없다. 상위 모듈이 하위 모듈을 의존하고 있으니까

이거랑 다른게 뭔데?

올바른 DIP는 객체 본인 입장에서 생각하는 것이다.

'임의의 데이터베이스에 저장'이 아니라 '나는 무언가를 저장한다'가 추상화이다.

'메일 서비스에 요청'이 아니라 '알림을 전송한다'가 추상화이다.

도메인에는 구현체가 있으면 안된다. 비즈니스 요구사항만 있어야 한다.

응용(서비스)가 필요한 것을 실행한다. 도메인은 비즈니스를 담당한다.

DIP를 잘하려면 고수준 모듈 입장에서 추상화해야한다.

 

💭 Aggregate(집합), 참조

많은 객체들의 관계. 숲(고수준)의 관리를 잃어버리게 된다.

나무(각 객체)들에게 초점이 맞춰지게 된다.

모든 객체가 동시에 사용되지 않는다. 각각의 책임과 역할이 나누어져있다.

상위수준에서 관련된 객체를 묶어서 큰 그림으로 봐야한다.

이러라고 나온 개념이 Aggregate (n 에그리것, v 에그리게이트), 한글로 군집화

한 Aggregate에 하나의 Root를 두고 관리를한다.

• 관련된 객체들의 묶음 (집합)
• 데이터 변경시 한 단위로 처리됨
• 비슷한 라이프 사이클을 갖는 객체들 (삭제 시 함께 삭제됨)
• 경계를 가짐. 한 객체는 하나의 Aggregate를 가짐
• 필요성 : 많은 도메인 모델들을 간단하고 이해 가능한 수준으로 묶을 수 있음
• 연관의 개수를 줄여서 복잡도를 감소시킬 수 있음

Order order = orderRepository.findById(orderId); // Aggregate 완전체를 가져옴

// 작업은 Aggregate의 Root로 명령을 내림.
// '추상화된 비즈니스 작업'을 요청함. 구체적인 내용은 적지 않음
order.changeShippingInfo(newShippingInfo);
order.cancle();

 

요구사항을 열심히 쳐다보면 쉽게 쪼갤 수 있는 군이 있음.

하지만 애매한 경우도 많음. Moive, Showing, Discount 어떻게 쪼개야 하는걸까?

ACG의 경계는 규칙, 트랜잭션 범위로 쪼개면 됨.

두 개가 따로 놀 수 있는가? = 다른 경계를 가지고 있는가? = 다른 ACG인가?

예를 들어 '할인'은 영화와 함께 동작함

혼자서 따로 놀 수 없음 = Movie Aggregate

 

하지만 할인 정책이 복잡해지면? SRP (단일책임원칙)을 적용해야함. -> AGG 경계가 달라짐

트랜잭션 범위(AGG 경계)는 언제나 바뀔 수 있음.

 

JPA를 처음 쓰면 아래와 같은 객체 그래프 탐색이 너무 편함

근데 이는 잠재적인 문제가 있음. '오용'

마치 상속을 기능 재사용으로 사용하는 것처럼 다른영역의 기능을 아무렇지 않게 바꿈

상영객체가 Discount를 바꾸는건 매우 이상한 동작임. 하지만 참조가 가능하기에 Side-Effect 발생

+ DBA와의 갈등. 객체에서는 편하지만 SQL문은 복잡하게 나감. 성능이 떨어짐

특히 설계 초창기에는 이런게 눈에 보이지 않음. 편리함에 익숙해져 이상한 코드를 만듦.

서로의 참조가 복잡하다= 수정과 확장이 힘들다 = MSA(마이크로 서비스 아키텍쳐)는 꿈도 꾸지 마라

그래서 결론은? AGG간은 ID로만 참조해라. 조금 불편하지만 응집도를 높이고 확장성을 챙길 수 있다.

• 참조 복잡도를 낮출 수 있다. (모델과 구현이 깔끔해진다)
• 오용을 방지하여 응집도를 강화한다.
• AGG별 확장이 쉽다.
• 조회 성능이 좋아진다.
• 그러나 사용하기 불편해진다. 더 많은 코드가 생긴다.

Q/A : 아는데.. 아는데요 DBA가 성능 최적화를 위해서 테이블을 8개를 조인해서 가져오래요

➡ 꼭 ORM이 있어야 Aggregate를 구현할 수 있는게 아님.

➡ 구체적인 기술이 아니라, 추상화된 도메인을 중심으로 Aggregate를 생각.

➡ CQRS도 고려해볼 것

 

💭 DBA를 속이는 방법 CQRS

복잡한 도메인의 조회 특징 : 여러 AGG에 걸쳐서 데이터를 접근함

빠르게 조회하기 위해서 한방 쿼리에, 한방에 조회해야함 (Left Join, DB 전용기능 필요해)

이를 하나의 모델로 처리하려고 하면, 도메인 모델이 진짜 더럽게 복잡해짐

이럴 때는 Lazy.. 이거는 모아서 Batch... 이건 Eager..어..? N+1 문제가 터졌네?

 

간단한 해결책 : CQRS

하나의 모델로 처리하던 것을 [상태 변경 모델]과 [조회 모델]을 분리

상태변경과 조회를 다른 아키텍처를 사용

상태변경은 JPA를 써서 객체적으로 쉽게 짜고 조회는 MyBatis 같은 걸로 SQL을 직접 짜면 해결

➡ 상태 변경은 보통 1,2개의 개체밖에 안건드림. (DBA와 시비 붙을일 x)

➡ 조회는 정말 여러테이블을 조회해야함 (한방 쿼리를 여러번 나눠서 조회한다? DBA 열불 오르기 시작)

여기서 더 나아가서, 조회 트래픽이 엄청나다면 아예 DB를 쪼개서 확장하는 방법도 있음

CQRS를 하면 도메인 설계를 하는데 '조회 성능'을 고려할 필요가 없음.

조회쪽 모델은 캐시를 적용하고, 쿼리를 뜯어고치면 되는거고

도메인 모델은 그대로 객체지향적으로 사용하면 됨. (상태변경은 SQL문이 복잡하지 않음)

단점 : 귀찮음. 데이터 동기화문제도 있고, CQRS로 나누면서 시스템이 복잡해짐 

결국 이것도 트레이드 오프임. 도메인 모델을 깔끔하게 가져가는대신, 시스템을 복잡하게 만들 것 인가?

CQRS를 배우고 좋은 설계에 대한 학습은 더 오래 걸리겠지만

한번 배워놓은걸 사용하는데 엄청난 시간이 걸리진 않음. 더 많은 코드를 작성한다고 더 오래걸리는게 아님.

우리 프로젝트 도메인이 복잡하고 미래에 트래픽이 증가할 것이 걱정된다면 미리 작업해놓으면 분명 도움이 될 것임.

 

💭 이벤트와 트랜잭션

예매를 취소를 하면 환불을 해줘야함.

이는 도메인 모델에서 처리를 해야할까?

근데 잘 생각해보면 '외부 서비스'를 사용하는 경우 트랜잭션 처리가 매우 까다로움

• 환불을 처리하다가 외부서비스(ex 이메일)이 작동하지 않으면 실패인가?
• 환불을 처리하다가 외부서비스가 블럭킹되면 성능이 떨어진다. 이를 트랜잭션 단위로 묶어서 기다려야 할까?
• 예매 취소와 환불 로직이 한 코드안에 있는게 맞을까? SRP는?
• 기능이 추가되면 DI로 주입을..? '문자로 환불 내역을 보낸다' 라는 추가 기능에 환불 도메인을 변경해야할까?

 

이벤트란 무엇인가?

- 과거에 벌어진 어떤 것. 주로 상태가 변화함

• 영화 추가함 (NewMoviedCreated)
• 예매함 (RevervationCreated)
• 영화 상영 일정 추가함(ShowingAdded)
• 영화 정보 변경함 (MovieInfoChanged)
• 영화 가격 정책 변경함(PricePolicyUpdated)
• 예매 취소함(ReservationCanceled)

이벤트만 있으면 아무런 동작을 하지 않음.

이벤트를 발생시키는 주체와 이벤트를 받아서 처리할 주체가 있어야함.

이벤트 디스패쳐는 생성된 이벤트를 처리할 Handler에게 전달하는 역할

이벤트를 트리거로 사용할 수 있음. 다른 이벤트를 호출

 

💭 도메인과 이벤트

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

[~할때, ~가 발생하면, 만약 ~하면] 등의 요구사항이 상태를 변경한다면, 이벤트로 표현할 수 있음

상태의 변경을 이벤트로 변경하게되면, 책임을 나눌 수 있음.

도메인에서 취소로직을 가지고, 상태를 변경하는게 아님

도메인에서는 '취소 이벤트'를 만들고, 이벤트 디스패쳐에 이벤트를 넘겨서 발생시킴

예매는 더이상 환불로직에 대해서 알 필요가 없음. SRP

또한 이벤트-디스패쳐 구조는 이미 안드로이드, UI에서 익숙한 구조임.

이벤트 핸들러의 기능을 확장하기도 쉬움 '도메인을 바꾸지 않고 기능을 추가할 수 있음' OCP

근데요.. 이벤트로하면... 트랜잭션 처리가 복잡해지는데 동기화는 어떻게 하나요?

우리의 요구사항은 항상 애매한 단어를 많이 사용함.

'이거 하자말자, 이걸 해주세요' ➡ 과연 이게 즉시일까? 예매 취소후, 바로 환급을 해야할까?

이메일 발송을 취소한다고 회원가입을 못할 이유가 없음.

데이터 일관성이, 즉시가 아니라 수초, 수분뒤에 해결되도 괜찮은 경우가 많음

그래서 이벤트를 사용해도 괜찮다는 거임.

 

가장 쉬운 방법은 메시지 큐를 사용하는 것.

• 고민사항 : 실패하면 재전송은 어떻게 하나

다른 방법은 로컬 이벤트 핸들러가 DB에 저장하고, 대리자(포워더)가 일정주기로 DB를 읽어서 전달하는 방법

• 이벤트 로직이 단순해짐. 그러나 포워더를 따로 만들어줘야함

 

3번째 방법. 로컬 이벤트 핸들러가 DB에 저장하는 건 같은데, 그걸 상대방이 읽는 것 (pull)

이벤트를 API 형태로 제공해서 니가 읽어라고 하는 것.

• 기존의 메시지큐(RebbitMQ) 는 클라이언트에게 이벤트를 줘야함. 관리해줘야함.
• 아래와 같은 방식의 메시지큐(Kafka)는 하는 일이 없음. 매우빠름. 니가 알아서 가져가라 이마리야

다만 이벤트를 도입할 때는 조심해야함.

• 이벤트 도착 순서를 고려해야함
• 이벤트 발송 실패시 재발송을 어떻게 할 것인가
• 이벤트를 어떻게 재처리 할 것인가. (*재발송시 순서가 꼬임)
  그래서 2번, 3번의 니가 알아서 해~ 방식으로 이벤트를 발송하는 것.

참고로 굳이 RebbitMQ, Kafka같은 걸 쓸 필요 없음. (특히 신입이 자주그럼. 프로젝트 구조가 있어보이니까)

기술에 집착하지마라 스프링 + DB만 있어도 구현 가능하다.

 

개발자는 균형감이 있어야한다. 결국 모든 것은 트레이드 오프이다. 적당히 해야한다.

• DIP를 한답시고 모든 곳에 인터페이스를 박지마라. 인터페이스도 트레이드 오프이다.
• Aggregate를 지 맘대로 짜지마라. 현재 우리 서비스의 구조, DBA와 의논하고 천천히 도입하라
• CQRS, 이벤트도 마찬가지

다만 내가 아는게 없다면? 일단 질러보자. 욕먹으면서 어거지로 사용해보자. 피드백을 받으며 균형감을 배워나가자.

 

 

질문

 

메시지를 주는건 어찌보면 얍삽한거지. 니가해!

다만 DDD Actor에서 말하는 메시지는 비동기 방식의 연산처리와 가깝습니다. 각 actor가 뽑아내는 이벤트

 

고수준은 저수준에 의존하지 않는다. DIP 의존성의 방향을 역전하거라