<div id="readability-page-1" class="page"><div>CQRS는 내가 Greg Young을 통해 처음 듣게 된 Command와 Query의 책임 분할을 지향하는 패턴이다.CQRS는 정보를 업데이트 할때와 조회할 때 다른 모델을 사용하는 것이 가장 핵심이다.다만, 일부 경우에는 이점이 있지만, 대부분의 경우에는 CQRS를 적용하면 복잡성이 높아지는 위험성이 있다.사람들이 정보 시스템과 교류하는 일반적인 방법은 CRUD 저장소로 사용하는 것이다.이 말을 통해 우리가 레코드를 읽고, 쓰고, 기존의 레코드를 업데이트하고, 다 사용한 레코드를 삭제하는 추상적인 어떤 레코드 구조 모델이 있다는 것을 알려주고 싶다.우리는 언제나 레코드들을 가져오거나 저장하기 위해 정보 시스템과 교류한다.하지만 요구사항이 점점 복잡해질 수록, 우리는 모델에게 점점 멀어진다.여러 레코드들을 하나로 합치거나 여러 장소의 정보를 결합해서 가상의 레코드를 형성하는 경우처럼 기존의 레코드 저장소와는 다른 방식으로 정보를 가져오고 싶을 수 있다.예를 들어 업데이트하는 경우 특정한 데이터의 조합 만을 저장하거나, 제공한 방식과 다르게 전달되는 데이터에 대한 validation 조건을 발견할 수 있다.<figure><img alt="" src="https://miro.medium.com/max/1274/1*CARqd8rc5bYXN__4KHYxZg.png" width="637" height="408" role="presentation"></figure>이런 상황이 발생할 때 다양한 방식으로 정보가 표현되는 것을 발견하게 된다.사용자가 정보와 상호 작용하게 될 때 사용자의 행동에 따라서 정보는 다른 방식으로 표현된다.개발자들은 일반적으로 모델의 핵심 요소들을 다루기 위해 그들만의 개념적 모델을 사용한다.도메인 모델을 사용하는 경우 일반적으로 모델은 도메인을 개념적으로 표현한 것이 되고 영속성 저장소도 개념적 모델에 가능한 한 가깝게 만든다.이런 여러 개의 표현 계층을 가진 구조가 복잡해지더라도, 사람들은 여전히 공통된 한가지의 개념적 표현을 사용해서 전달 받는다.CQRS는 개념적 모델을 업데이트와 읽기로 나누는 방식을 제시한다.CommandQuerySeparation 에서 사용한 Command와 Query의 용어 정의를 참고하자.(Command: Change the state of a system but do not return a value. 시스템의 상태를 변경하고 값을 반환받지 않는 행동.Queries: Return a result and do not change the observable state of the system. 값을 반환받고 관측 가능한 시스템의 상태를 변경하지 않는 행동 <a href="https://www.martinfowler.com/bliki/ObservableState.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/ObservableState.html</a> 참고)같은 개념적 모델에 Command와 Query 두가지 모두를 사용하는 건 모델을 복잡하게 만들고 특히 복잡한 도메인 일 수록 더 복잡해지기 때문에 두 행동을 나누는 것을 제시한다.<figure><div><img alt="" src="https://miro.medium.com/max/1274/1*UaEJN8gaFiVhbYU1cOdXZA.png" width="637" height="464" sizes="637px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*UaEJN8gaFiVhbYU1cOdXZA.png?q=20"></div></figure>모델의 나눈다는 것은 일반적으로 객체 모델이 다르거나, 다른 로직에서 실행되거나 다른 하드웨어로 분할되는 것을 의미할 것이다.웹을 예로 들어보면 사용자가 보는 웹페이지가 query 모델을 통해 렌더링 된다는 것을 알 수 있다.사용자가 변경사항을 만든다면, 변경사항의 반영은 분리된 command 모델로 라우팅 되고 변경에 대한 결과는 query 모델과 통신해 결과를 렌더링할 것이다.위의 예시는 여러 방식으로 구현 할 수 있다.예를 들어 인 메모리에 있는 두 개의 모델은 같은 데이터베이스를 공유하고 있는데 이때 데이터베이스는 두 모델 간의 통신 역할을 할 수 있다.반면에 두 모델이 나뉘어진 데이터베이스를 사용한다면, query 용도로 사용하는 데이터베이스를 효과적으로 실시간 ReportingDatabase 로 만들 수 있다.다만 이런 경우에는 두 개의 모델 간 또는 각 모델의 데이터베이스 간에 특정한 통신이 필요 할 수 있다.(Reporting Database : <a href="https://www.martinfowler.com/bliki/ReportingDatabasse.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/ReportingDatabasse.html</a>역자: Read-only 데이터베이스라고 이해하는 편이 간편하다. 세부적인 정의는 링크 참조)두 모델이 서로 다른 object 모델은 아닐 수 있다.예를 들면 관계형 데이터베이스의 view와 같이 object가 command와 query를 위해 다른 인터페이스를 제공하는 경우다.다만, CQRS는 완전하게 분리하는 방식을 추가한다고 한다.CQRS는 일부 다른 아키텍쳐 패턴과 자연스럽게 맞아떨어진다.<ul><li id="876d">CRUD 와 같은 단일한 표현으로부터 벗어나게 되면, 좀 더 쉽게 작업 중심의 UI로 옮겨 갈 수 있다. (작업 중심 UI: Task based UI)</li><li id="47f2">CQRS는 event-based programming models와도 잘 맞는다. 일반적으로 CQRS 시스템은 Event Collaboration을 이용해 나누어진 서비스 간의 통신을 하는 것에 나누어져서 들어간다. 이러한 구조는 해당 서비스가 Event Sourcing의 이점을 쉽게 가질 수 있게 해준다. (Evnet-based programming models: <a href="https://www.martinfowler.com/eaaDev/EventNarrative.html" rel="noopener nofollow">https://www.martinfowler.com/eaaDev/EventNarrative.html</a> Event Collaboration: <a href="https://www.martinfowler.com/eaaDev/EventCollaboration.html" rel="noopener nofollow">https://www.martinfowler.com/eaaDev/EventCollaboration.html</a> Event Sourcing: <a href="https://www.martinfowler.com/eaaDev/EventSourcing.html" rel="noopener nofollow">https://www.martinfowler.com/eaaDev/EventSourcing.html</a>)</li><li id="48dc">나누어진 모델은 모델의 일관성을 유지하는 게 어렵지 않을까 하는 의문을 가지게 한다. 의문이 커질수록 eventual consistency의 사용을 하고 싶어진다. (Eventual Consistency: <a href="https://www.allthingsdistributed.com/2008/12/eventually_consistent.html" rel="noopener nofollow">https://www.allthingsdistributed.com/2008/12/eventually_consistent.html</a>)</li><li id="bb5d">많은 도메인은, 업데이트되는 시점에 많은 로직이 필요하게 된다. 그렇기 때문에 query 모델을 단순화 하는데 EagerReadDerivation을 사용하는 것이 합리적이다. (EagerReadDerivation: <a href="https://www.martinfowler.com/bliki/EagerReadDerivation.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/EagerReadDerivation.html</a>)</li><li id="19bb">만약 command 모델이 모든 업데이트에 대해서 이벤트를 발행한다면, query 모델을 EventPosts로 구현하고 MemoryImages화 하는 것을 허용하는 것을 통해서, 데이터베이스와 지나치게 많은 상호작용을 피할 수 있다. (EventPosts: <a href="https://www.martinfowler.com/bliki/EventPoster.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/EventPoster.html</a> MemoryImage: <a href="https://www.martinfowler.com/bliki/MemoryImage.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/MemoryImage.html</a>)</li><li id="ea71">CQRS는 복잡한 도메인과 잘 맞고 Domain-driven Design과 함께 사용하는 게 좋다. (Domain-driven design: <a href="https://www.amazon.com/gp/product/0321125215?ie=UTF8&amp;tag=martinfowlerc-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0321125215" rel="noopener nofollow">https://www.amazon.com/gp/product/0321125215?ie=UTF8&amp;tag=martinfowlerc-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0321125215</a> (도메인 주도 설계))</li></ul><h2 id="b814">언제 사용할까?</h2></div><div>다른 패턴들과 마찬가지로 CQRS는 어떤 곳에는 유용하고, 어떤 곳에는 유용하지 못하다.많은 시스템은 CRUD 사고 모델과 잘 맞고 그 스타일을 유지해야 한다.CQRS는 시스템에서 주의를 기울여야 하는 모든 곳에서 기본 개념에 중대한 변화가 생긴다.그렇기 때문에 충분한 혜택과 이득이 있지 않은 한 적용 하지 말아야 한다.내가 CQRS를 성공적으로 사용하기 까지, 대부분의 경우에 CQRS는 소프트웨어 시스템을 심각한 어려움으로 빠트리는 힘이 있는지 잘 하기 어려운 상황으로 끌어들인다.CQRS는 시스템의 특정한 부분(DDD 표현으로는 Bounded Context)에서만 사용돼야 하고, 시스템 전체에서 사용해서는 안 된다.이러한 사고방식은 각 Bounded Context는 개별적으로 모델링을 해야 한다는 의미다.(Bounded Context: <a href="https://www.martinfowler.com/bliki/BoundedContext.html" rel="noopener nofollow">https://www.martinfowler.com/bliki/BoundedContext.html</a>)지금까지 나는 두가지 관점에서 좋은 점을 설명했다.첫째로는, 일부 복잡한 도메인은 CQRS를 통해 한결 쉽게 해결 할 수 있을 것이다.하지만 CQRS는 소수의 경우에만 적합하다는 점을 강조하고 싶다.일반적으로 command와 query를 모두 포함하고 공유하는 모델이 한결 쉽고 CQRS가 잘 맞지 않는 도메인에서 사용하는 경우, 복잡성이 올라가고 이런 복잡성은 생산성의 감소와 위험부담의 증가를 부른다.다른 이점은, 높은 퍼포먼스의 애플리케이션을 제어한게 된다는 것이다.CQRS는 command와 query가 분리되어 있기 때문에 개별적으로 확장 가능하게 해주고, 읽기와 쓰기 사이에 큰 차이가 있는 경우 관리를 쉽게 해준다.그게 아니라도 서로 다른 최적화 전략을 두 부분에 적용할 수 있다.예를 들어 query 데이터베이스와 command 데이터베이스를 분할하는 방식이 있다.만약 도메인이 CQRS와는 잘 맞지 않지만, query들이 복잡성을 더하고 성능에 문제를 일으킨다면 ReportingDatabase 를 사용하자.CQRS는 모든 query에 대해 분할된 모델을 사용한다.이러한 이점들에도 CQRS를 사용하는 것에는 많은 주의를 기울여야 한다.많은 정보 시스템들은 정보를 기반으로 한가지 방식으로 읽기와 쓰기를 하는 것에 잘 맞는데, 여기에 CQRS를 더하는 건 불필요한 복잡성을 늘릴 뿐이다.나는 유능한 팀들마저도 부당한 복잡성을 증가 시켜 생산성을 크게 떨어트리는 경우를 많이 보았다.CQRS는 분명 사용을 고려해 볼만한 좋은 패턴이지만, 사용 하기 어렵고 잘못 다루게 되면 중요한 부분들을 버리게 된다는 것을 주의해야 한다.</div></div>

Stories by Jooho Son on Medium

원문 : https://martinfowler.com/bliki/CQRS.html
마틴 파울러 님은 번역에 대한 별다른 제제를 두지 않으셨습니다.
참고용 및 공유 용으로 번역해서 포스팅 합니다.
모든 이미지는 마틴 파울러 님의 원문으로 부터 가져왔습니다.
(번역에 대한 링크: https://martinfowler.com/faq.html)
읽어보시고 조언해 주실 부분이 있다면 댓글 부탁드립니다.
CQRS
CQRS는 내가 Greg Young을 통해 처음 듣게 된 Command와 Query의 책임 분할을 지향하는 패턴이다.
CQRS는 정보를 업데이트 할때와 조회할 때 다른 모델을 사용하는 것이 가장 핵심이다.
다만, 일부 경우에는 이점이 있지만, 대부분의 경우에는 CQRS를 적용하면 복잡성이 높아지는 위험성이 있다.
사람들이 정보 시스템과 교류하는 일반적인 방법은 CRUD 저장소로 사용하는 것이다.
이 말을 통해 우리가 레코드를 읽고, 쓰고, 기존의 레코드를 업데이트하고, 다 사용한 레코드를 삭제하는 추상적인 어떤 레코드 구조 모델이 있다는 것을 알려주고 싶다.
우리는 언제나 레코드들을 가져오거나 저장하기 위해 정보 시스템과 교류한다.
하지만 요구사항이 점점 복잡해질 수록, 우리는 모델에게 점점 멀어진다.
여러 레코드들을 하나로 합치거나 여러 장소의 정보를 결합해서 가상의 레코드를 형성하는 경우처럼 기존의 레코드 저장소와는 다른 방식으로 정보를 가져오고 싶을 수 있다.
예를 들어 업데이트하는 경우 특정한 데이터의 조합 만을 저장하거나, 제공한 방식과 다르게 전달되는 데이터에 대한 validation 조건을 발견할 수 있다.
이런 상황이 발생할 때 다양한 방식으로 정보가 표현되는 것을 발견하게 된다.
사용자가 정보와 상호 작용하게 될 때 사용자의 행동에 따라서 정보는 다른 방식으로 표현된다.
개발자들은 일반적으로 모델의 핵심 요소들을 다루기 위해 그들만의 개념적 모델을 사용한다.
도메인 모델을 사용하는 경우 일반적으로 모델은 도메인을 개념적으로 표현한 것이 되고 영속성 저장소도 개념적 모델에 가능한 한 가깝게 만든다.
이런 여러 개의 표현 계층을 가진 구조가 복잡해지더라도, 사람들은 여전히 공통된 한가지의 개념적 표현을 사용해서 전달 받는다.
CQRS는 개념적 모델을 업데이트와 읽기로 나누는 방식을 제시한다.
CommandQuerySeparation 에서 사용한 Command와 Query의 용어 정의를 참고하자.
(Command: Change the state of a system but do not return a value. 시스템의 상태를 변경하고 값을 반환받지 않는 행동.
Queries: Return a result and do not change the observable state of the system. 값을 반환받고 관측 가능한 시스템의 상태를 변경하지 않는 행동 https://www.martinfowler.com/bliki/ObservableState.html 참고)
같은 개념적 모델에 Command와 Query 두가지 모두를 사용하는 건 모델을 복잡하게 만들고 특히 복잡한 도메인 일 수록 더 복잡해지기 때문에 두 행동을 나누는 것을 제시한다.
모델의 나눈다는 것은 일반적으로 객체 모델이 다르거나, 다른 로직에서 실행되거나 다른 하드웨어로 분할되는 것을 의미할 것이다.
웹을 예로 들어보면 사용자가 보는 웹페이지가 query 모델을 통해 렌더링 된다는 것을 알 수 있다.
사용자가 변경사항을 만든다면, 변경사항의 반영은 분리된 command 모델로 라우팅 되고 변경에 대한 결과는 query 모델과 통신해 결과를 렌더링할 것이다.
위의 예시는 여러 방식으로 구현 할 수 있다.
예를 들어 인 메모리에 있는 두 개의 모델은 같은 데이터베이스를 공유하고 있는데 이때 데이터베이스는 두 모델 간의 통신 역할을 할 수 있다.
반면에 두 모델이 나뉘어진 데이터베이스를 사용한다면, query 용도로 사용하는 데이터베이스를 효과적으로 실시간 ReportingDatabase 로 만들 수 있다.
다만 이런 경우에는 두 개의 모델 간 또는 각 모델의 데이터베이스 간에 특정한 통신이 필요 할 수 있다.
(Reporting Database : https://www.martinfowler.com/bliki/ReportingDatabasse.html
역자: Read-only 데이터베이스라고 이해하는 편이 간편하다. 세부적인 정의는 링크 참조)
두 모델이 서로 다른 object 모델은 아닐 수 있다.
예를 들면 관계형 데이터베이스의 view와 같이 object가 command와 query를 위해 다른 인터페이스를 제공하는 경우다.
다만, CQRS는 완전하게 분리하는 방식을 추가한다고 한다.
CQRS는 일부 다른 아키텍쳐 패턴과 자연스럽게 맞아떨어진다.
CRUD 와 같은 단일한 표현으로부터 벗어나게 되면, 좀 더 쉽게 작업 중심의 UI로 옮겨 갈 수 있다.
(작업 중심 UI: Task based UI)
CQRS는 event-based programming models와도 잘 맞는다. 일반적으로 CQRS 시스템은 Event Collaboration을 이용해 나누어진 서비스 간의 통신을 하는 것에 나누어져서 들어간다. 
이러한 구조는 해당 서비스가 Event Sourcing의 이점을 쉽게 가질 수 있게 해준다.
(Evnet-based programming models: https://www.martinfowler.com/eaaDev/EventNarrative.html
Event Collaboration: https://www.martinfowler.com/eaaDev/EventCollaboration.html
Event Sourcing: https://www.martinfowler.com/eaaDev/EventSourcing.html)
나누어진 모델은 모델의 일관성을 유지하는 게 어렵지 않을까 하는 의문을 가지게 한다. 의문이 커질수록 eventual consistency의 사용을 하고 싶어진다.
(Eventual Consistency: https://www.allthingsdistributed.com/2008/12/eventually_consistent.html)
많은 도메인은, 업데이트되는 시점에 많은 로직이 필요하게 된다. 그렇기 때문에 query 모델을 단순화 하는데 EagerReadDerivation을 사용하는 것이 합리적이다.
(EagerReadDerivation: https://www.martinfowler.com/bliki/EagerReadDerivation.html)
만약 command 모델이 모든 업데이트에 대해서 이벤트를 발행한다면, query 모델을 EventPosts로 구현하고 MemoryImages화 하는 것을 허용하는 것을 통해서, 데이터베이스와 지나치게 많은 상호작용을 피할 수 있다.
(EventPosts: https://www.martinfowler.com/bliki/EventPoster.html
MemoryImage: https://www.martinfowler.com/bliki/MemoryImage.html)
CQRS는 복잡한 도메인과 잘 맞고 Domain-driven Design과 함께 사용하는 게 좋다.
(Domain-driven design: https://www.amazon.com/gp/product/0321125215?ie=UTF8&tag=martinfowlerc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321125215 (도메인 주도 설계))
언제 사용할까?
다른 패턴들과 마찬가지로 CQRS는 어떤 곳에는 유용하고, 어떤 곳에는 유용하지 못하다.
많은 시스템은 CRUD 사고 모델과 잘 맞고 그 스타일을 유지해야 한다.
CQRS는 시스템에서 주의를 기울여야 하는 모든 곳에서 기본 개념에 중대한 변화가 생긴다.
그렇기 때문에 충분한 혜택과 이득이 있지 않은 한 적용 하지 말아야 한다.
내가 CQRS를 성공적으로 사용하기 까지, 대부분의 경우에 CQRS는 소프트웨어 시스템을 심각한 어려움으로 빠트리는 힘이 있는지 잘 하기 어려운 상황으로 끌어들인다.
CQRS는 시스템의 특정한 부분(DDD 표현으로는 Bounded Context)에서만 사용돼야 하고, 시스템 전체에서 사용해서는 안 된다.
이러한 사고방식은 각 Bounded Context는 개별적으로 모델링을 해야 한다는 의미다.
(Bounded Context: https://www.martinfowler.com/bliki/BoundedContext.html)
지금까지 나는 두가지 관점에서 좋은 점을 설명했다.
첫째로는, 일부 복잡한 도메인은 CQRS를 통해 한결 쉽게 해결 할 수 있을 것이다.
하지만 CQRS는 소수의 경우에만 적합하다는 점을 강조하고 싶다.
일반적으로 command와 query를 모두 포함하고 공유하는 모델이 한결 쉽고 CQRS가 잘 맞지 않는 도메인에서 사용하는 경우, 복잡성이 올라가고 이런 복잡성은 생산성의 감소와 위험부담의 증가를 부른다.
다른 이점은, 높은 퍼포먼스의 애플리케이션을 제어한게 된다는 것이다.
CQRS는 command와 query가 분리되어 있기 때문에 개별적으로 확장 가능하게 해주고, 읽기와 쓰기 사이에 큰 차이가 있는 경우 관리를 쉽게 해준다.
그게 아니라도 서로 다른 최적화 전략을 두 부분에 적용할 수 있다.
예를 들어 query 데이터베이스와 command 데이터베이스를 분할하는 방식이 있다.
만약 도메인이 CQRS와는 잘 맞지 않지만, query들이 복잡성을 더하고 성능에 문제를 일으킨다면 ReportingDatabase 를 사용하자.
CQRS는 모든 query에 대해 분할된 모델을 사용한다.
이러한 이점들에도 CQRS를 사용하는 것에는 많은 주의를 기울여야 한다.
많은 정보 시스템들은 정보를 기반으로 한가지 방식으로 읽기와 쓰기를 하는 것에 잘 맞는데, 여기에 CQRS를 더하는 건 불필요한 복잡성을 늘릴 뿐이다.
나는 유능한 팀들마저도 부당한 복잡성을 증가 시켜 생산성을 크게 떨어트리는 경우를 많이 보았다.
CQRS는 분명 사용을 고려해 볼만한 좋은 패턴이지만, 사용 하기 어렵고 잘못 다루게 되면 중요한 부분들을 버리게 된다는 것을 주의해야 한다.

[번역] 마틴 파울러 CQRS 포스팅

댓글