2021.11.12 TIL

pbg0205·2021년 11월 13일
0

TIL

목록 보기
9/13

(어제 TIL 적을라고 생각하다가 잠들어서 적지 못한 TILㅎㅎ)

기억해보니 어제 면접 질문 중에 CQRS를 아는지에 관한 질문이 있었는데 제대로 대답하지 못해서 간단하게 개념이라도 정리했다.


1. CQRS(Command and Query Responsibility Segregation)

1. CQRS이 생긴 이유

  1. 간단하고 기본적인 CRUD작업을 하는 경우, 쿼리와 업데이트를 동일한 데이터 모델에 사용한다.
  2. 더 복잡한 애플리케이션의 경우, 모델이 너무 많은 작업을 수행할 수도 있다.
    • 어플리케이션의 읽기 쪽에서 다른 쿼리를 수행할 수도 있어 복잡한 개체 매핑이 발생할 수도 있고
      (여러 객체가 통합된 dto를 반환해야 하는 경우로 이해함)
    • 모델은 쓰기 쪽에서 복잡한 유효성 검사 또는 비즈니스 로직을 구현할 수도 있다.
    • 이걸 한 모델에 모두 담아두기에는 너무 많은 책임을 맡게 된다.
    • 이를 해결하기 위해 나온 방법론이 CQRS!

2. 그래서 CQRS란??

  1. 데이터 저장소에 대한 조회(Query)와 명령(Command)을 구분하는 다른 모델로 관리하는 방식

    • SQL의 Query와 command
      • Query : select
      • Command : insert, update, delete

  2. 명령은 데이터 중심이 아닌 작업 기반이어야 하고, 비동기 처리를 위해 큐가 배치될 수 있다.
    (동기보다는 비동기를 선호하는 방식인 것 같다!)

  3. 쿼리는 데이터 베이스를 수정하지 않는다. 쿼리는 도메인 정보를 캡슐화하지 않는 DTO를 반환한다.
    (음... 아직 와닿지 않는다. 여러 객체를 조회하는 쿼리일 때 각각 요소를 단순 데이터 타입으로 반환한다는 얘기인 것 같다.)


3. CQRS의 이점

  1. 독립적인 크기 조정 : CQRS를 통해 읽기 및 쓰기 워크로드를 독립적으로 확장하고 더 적은 수의 잠금 경합이 발생할 수 있음.
    (책임을 분리하여 확장하기 용이하고 작은 단위로 트랜잭션 격리 수준을 지정할 수 있는 방법인 것 같다.)

  2. 최적화된 데이터 스키마 : 읽기 쪽에서는 쿼리에 최적화된 스키마, 쓰기 쪽은 업데이트에 최적화된 스키마를 사용할 수 있다.

  3. 관심사의 분리 : 읽기 및 쓰기 쪽을 구분하면 유지 가능하고 유연한 모델을 생성할 수 있다.

  1. 단순한 쿼리 읽기 데이터베이스에서 구체화된 뷰를 저장하여 쿼리할 때 어플리케이션은 복잡한 조인을 방지할 수 있다.

처음 이해하는 정도로는 이 정도만 알고 있으면 좋을 것 같다. 아무래도 나는 김영한님께서 말씀하시는 야생형 스타일이라서 조만간 게시판 예제를 CQRS로 한번 적용해보는 것도 좋을 것 같다👍👍👍

4. Refrence

profile
🧑‍💻 steady developer

0개의 댓글