CQRS(명령 및 쿼리 책임 분리) 패턴Command and Query Responsibility Segregation (CQRS) pattern

CQRS(명령 및 쿼리 책임 분리) 패턴은 데이터 저장소에 대한 읽기 및 업데이트 작업을 구분합니다.The Command and Query Responsibility Segregation (CQRS) pattern separates read and update operations for a data store. 응용 프로그램에서 CQRS를 구현하면 성능, 확장성 및 보안을 극대화할 수 있습니다.Implementing CQRS in your application can maximize its performance, scalability, and security. CQRS로 마이그레이션하여 생성되는 유연성을 통해 시간이 지남에 따라 시스템이 더 잘 발전할 수 있으며 업데이트 명령이 도메인 수준에서 병합 충돌을 일으키지 않도록 합니다.The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.

문제The problem

기존 아키텍처에서 데이터베이스를 쿼리하고 업데이트하는 데 동일한 데이터 모델을 사용합니다.In traditional architectures, the same data model is used to query and update a database. 그러면 간단하고 기본적인 CRUD 작업에 적합합니다.That's simple and works well for basic CRUD operations. 그러나 더 복잡한 애플리케이션에서는 이 방법을 사용하기 어려울 수 있습니다.In more complex applications, however, this approach can become unwieldy. 예를 들어 애플리케이션은 읽기 쪽에서 다른 쿼리를 수행할 수 있습니다. 그러면 모양이 다른 DTO(데이터 전송 개체)를 반환합니다.For example, on the read side, the application may perform many different queries, returning data transfer objects (DTOs) with different shapes. 개체 매핑이 복잡해 질 수 있습니다.Object mapping can become complicated. 모델은 쓰기 쪽에서 복잡한 유효성 검사 및 비즈니스 논리를 구현할 수 있습니다.On the write side, the model may implement complex validation and business logic. 따라서 너무 많은 작업을 수행하는 과도하게 복잡한 모델이 될 수 있습니다.As a result, you can end up with an overly complex model that does too much.

읽기 및 쓰기 워크로드는 성능 및 규모 요구 사항이 매우 다른 비대칭인 경우가 많습니다.Read and write workloads are often asymmetrical, with very different performance and scale requirements.

기존 CRUD 아키텍처

  • 작업의 일부로 필요하지 않더라도 올바르게 업데이트해야 하는 추가 열이나 속성과 같이 데이터의 읽기 및 쓰기 표현 간에 불일치가 있는 경우가 많습니다.There is often a mismatch between the read and write representations of the data, such as additional columns or properties that must be updated correctly even though they aren't required as part of an operation.

  • 동일한 데이터 집합에서 작업을 병렬로 수행할 때 데이터 경합이 발생할 수 있습니다.Data contention can occur when operations are performed in parallel on the same set of data.

  • 기존의 접근 방식은 데이터 저장소 및 데이터 액세스 계층에 대한 로드 및 정보를 검색하는 데 필요한 쿼리의 복잡성으로 인해 성능에 부정적인 영향을 미칠 수 있습니다.The traditional approach can have a negative effect on performance due to load on the data store and data access layer, and the complexity of queries required to retrieve information.

  • 각 엔터티는 읽기 및 쓰기 작업의 대상이 되므로 잘못된 컨텍스트에서 데이터를 노출할 수 있으므로 보안 및 사용 권한 관리가 복잡해질 수 있습니다.Managing security and permissions can become complex, because each entity is subject to both read and write operations, which might expose data in the wrong context.

해결 방법Solution

CQRS는 데이터를 업데이트하는 명령을 사용하여 읽기 및 쓰기를 서로 다른 모델로 구분하고 데이터를 읽는 쿼리를 합니다.CQRS separates reads and writes into different models, using commands to update data, and queries to read data.

  • 명령은 데이터 중심이 아닌 작업을 기반으로 해야 합니다.Commands should be task based, rather than data centric. ("예약 호텔 객실"이 아니라 "예약 상태를 예약상태로 설정").("Book hotel room", not "set ReservationStatus to Reserved").
  • 명령은 동기적으로 처리되는 대신 비동기 처리를 위해 큐에 배치될 수 있습니다.Commands may be placed on a queue for asynchronous processing, rather than being processed synchronously.
  • 쿼리는 데이터베이스를 수정하지 않습니다.Queries never modify the database. 쿼리는 도메인 정보를 캡슐화하지 않는 DTO를 반환합니다.A query returns a DTO that does not encapsulate any domain knowledge.

그런 다음 다음 다이어그램과 같이 모델을 격리할 수 있지만 절대적인 요구 사항은 아닙니다.The models can then be isolated, as shown in the following diagram, although that's not an absolute requirement.

기본 CQRS 아키텍처

별도의 쿼리 및 업데이트 모델을 갖추면 디자인 및 구현이 간소화됩니다.Having separate query and update models simplifies the design and implementation. 그러나 한 가지 단점은 O/RM 도구와 같은 스캐폴딩 메커니즘을 사용하여 데이터베이스 스키마에서 CQRS 코드를 자동으로 생성할 수 없다는 것입니다.However, one disadvantage is that CQRS code can't automatically be generated from a database schema using scaffolding mechanisms such as O/RM tools.

더 높은 격리 수준을 위해 쓰기 데이터에서 읽기 데이터를 물리적으로 구분할 수 있습니다.For greater isolation, you can physically separate the read data from the write data. 이 경우에 읽기 데이터베이스는 쿼리에 대해 최적화된 고유한 데이터 스키마를 사용할 수 있습니다.In that case, the read database can use its own data schema that is optimized for queries. 예를 들어 복잡한 조인이나 복잡한 O/RM 매핑을 방지하기 위해 데이터의 구체화된 뷰를 저장할 수 있습니다.For example, it can store a materialized view of the data, in order to avoid complex joins or complex O/RM mappings. 다른 유형의 데이터 저장소도 사용할 수 있습니다.It might even use a different type of data store. 예를 들어 쓰기 데이터베이스가 관계형일 수 있는 반면 읽기 데이터베이스는 문서 데이터베이스입니다.For example, the write database might be relational, while the read database is a document database.

별도의 읽기 및 쓰기 데이터베이스를 사용하는 경우 동기화된 데이터베이스를 유지해야 합니다. 일반적으로 이 작업은 write 모델이 데이터베이스를 업데이트할 때마다 이벤트를 게시하여 수행됩니다.If separate read and write databases are used, they must be kept in sync. Typically this is accomplished by having the write model publish an event whenever it updates the database. 데이터베이스를 업데이트하고 이벤트를 게시하는 작업은 단일 트랜잭션에서 이루어져야 합니다.Updating the database and publishing the event must occur in a single transaction.

읽기 및 쓰기 저장소가 분리된 CQRS 아키텍처

읽기 저장소는 쓰기 저장소의 읽기 전용 복제본이거나 읽기 및 쓰기 저장소가 전혀 다른 구조일 수 있습니다.The read store can be a read-only replica of the write store, or the read and write stores can have a different structure altogether. 여러 읽기 전용 복제본을 사용하면 쿼리 성능이 향상될 수 있으며, 특히 읽기 전용 복제본이 응용 프로그램 인스턴스 가까이에 있는 분산 시나리오에서 확인할 수 있습니다.Using multiple read-only replicas can increase query performance, especially in distributed scenarios where read-only replicas are located close to the application instances.

읽기 및 쓰기 저장소를 분리하면 부하를 감안해 각 저장소를 적절하게 확장할 수도 있습니다.Separation of the read and write stores also allows each to be scaled appropriately to match the load. 예를 들어 보통 읽기 저장소는 쓰기 저장소보다 부하가 훨씬 더 높습니다.For example, read stores typically encounter a much higher load than write stores.

CQRS의 일부 구현에서는 이벤트 소싱 패턴을 사용합니다.Some implementations of CQRS use the Event Sourcing pattern. 이러한 패턴에서 애플리케이션 상태는 이벤트의 시퀀스로 저장됩니다.With this pattern, application state is stored as a sequence of events. 각 이벤트는 데이터에 대한 변경 집합을 나타냅니다.Each event represents a set of changes to the data. 현재 상태는 이벤트를 재생함으로써 구축됩니다.The current state is constructed by replaying the events. CQRS 컨텍스트에서 이벤트 소싱의 이점 중 하나는 다른 구성 요소 —를 알리는 데 동일한 이벤트를 사용할 수 있다는 점입니다. 특히 읽기 모델에 알립니다.In a CQRS context, one benefit of Event Sourcing is that the same events can be used to notify other components — in particular, to notify the read model. 읽기 모델은 현재 상태의 스냅샷을 만드는 데 이벤트를 사용합니다. 이것이 쿼리에 보다 효과적입니다.The read model uses the events to create a snapshot of the current state, which is more efficient for queries. 그러나 이벤트 소싱은 디자인에 복잡성을 추가합니다.However, Event Sourcing adds complexity to the design.

CQRS의 이점은 다음과 같습니다.Benefits of CQRS include:

  • 독립적 인 크기 조정.Independent scaling. CQRS를 통해 읽기 및 쓰기 워크로드를 독립적으로 확장하고 더 적은 수의 잠금 경합이 발생할 수 있습니다.CQRS allows the read and write workloads to scale independently, and may result in fewer lock contentions.
  • 최적화된 데이터 스키마.Optimized data schemas. 읽기 쪽에서는 쿼리에 최적화된 스키마를 사용하는 반면 쓰기 쪽에서는 업데이트에 최적화된 스키마를 사용할 수 있습니다.The read side can use a schema that is optimized for queries, while the write side uses a schema that is optimized for updates.
  • 보안.Security. 올바른 도메인 엔터티만 데이터에서 쓰기를 수행할 수 있는지 쉽게 확인할 수 있습니다.It's easier to ensure that only the right domain entities are performing writes on the data.
  • 문제 구분Separation of concerns. 읽기 및 쓰기 쪽을 구분하면 유지 가능하고 유연한 모델을 생성할 수 있습니다.Segregating the read and write sides can result in models that are more maintainable and flexible. 대부분의 복잡한 비즈니스 논리는 쓰기 모델로 이동합니다.Most of the complex business logic goes into the write model. 읽기 모델은 상대적으로 간단할 수 있습니다.The read model can be relatively simple.
  • 단순한 쿼리Simpler queries. 읽기 데이터베이스에서 구체화된 뷰를 저장하여 쿼리할 때 애플리케이션은 복잡한 조인을 방지할 수 있습니다.By storing a materialized view in the read database, the application can avoid complex joins when querying.

구현 문제 및 고려 사항Implementation issues and considerations

이 패턴을 구현하는 몇 가지 과제는 다음과 같습니다.Some challenges of implementing this pattern include:

  • 복잡성.Complexity. CQRS의 기본 개념은 간단합니다.The basic idea of CQRS is simple. 하지만 이벤트 소싱 패턴을 포함하는 경우에 특히 더 복잡한 애플리케이션 디자인을 만들 수 있습니다.But it can lead to a more complex application design, especially if they include the Event Sourcing pattern.

  • 메시징.Messaging. CQRS에 메시징이 필요하지 않지만 명령을 처리하고 업데이트 이벤트를 게시하는 데 공통적으로 메시징을 사용합니다.Although CQRS does not require messaging, it's common to use messaging to process commands and publish update events. 이 경우에 애플리케이션은 메시지 오류 또는 중복 메시지를 처리해야 합니다.In that case, the application must handle message failures or duplicate messages.

  • 최종 일관성.Eventual consistency. 읽기 및 쓰기 데이터베이스를 구분하는 경우 읽기 데이터는 기한이 경과되었을 수 있습니다.If you separate the read and write databases, the read data may be stale. 읽기 모델 저장소는 쓰기 모델 저장소의 변경 내용을 반영하도록 업데이트되어야 하며 사용자가 오래된 읽기 데이터를 기반으로 요청을 발행한 경우 를 감지하기 어려울 수 있습니다.The read model store must be updated to reflect changes to the write model store, and it can be difficult to detect when a user has issued a request based on stale read data.

이 패턴을 사용해야 하는 경우When to use this pattern

다음 시나리오에 대한 CQRS를 고려하십시오.Consider CQRS for the following scenarios:

  • 많은 사용자가 동일한 데이터에 병렬로 액세스하는 공동 작업 도메인입니다.Collaborative domains where many users access the same data in parallel. CQRS를 사용하면 도메인 수준에서 병합 충돌을 최소화하기에 충분한 세분성으로 명령을 정의할 수 있으며, 발생하는 충돌은 명령으로 병합할 수 있습니다.CQRS allows you to define commands with enough granularity to minimize merge conflicts at the domain level, and conflicts that do arise can be merged by the command.

  • 여러 단계를 거치거나 복잡한 도메인 모델을 사용하는 복잡한 프로세스를 통해 사용자를 안내하는 작업 기반 사용자 인터페이스.Task-based user interfaces where users are guided through a complex process as a series of steps or with complex domain models. 쓰기 모델에는 비즈니스 논리, 입력 유효성 검사 및 비즈니스 유효성 검사가 있는 전체 명령 처리 스택이 있습니다.The write model has a full command-processing stack with business logic, input validation, and business validation. write 모델은 연결된 개체 집합을 데이터 변경(DDD 용어의 집계)에 대한 단일 단위로 처리하고 이러한 개체가 항상 일관된 상태인지 확인할 수 있습니다.The write model may treat a set of associated objects as a single unit for data changes (an aggregate, in DDD terminology) and ensure that these objects are always in a consistent state. 읽기 모델에는 비즈니스 논리 또는 유효성 검사 스택이 없으며 뷰 모델에서 사용할 DTO만 반환합니다.The read model has no business logic or validation stack, and just returns a DTO for use in a view model. 결과적으로 읽기 모델과 쓰기 모델의 일관성이 유지됩니다.The read model is eventually consistent with the write model.

  • 데이터 읽기의 성능이 데이터 쓰기 성능과 별도로 미세 조정되어야 하는 시나리오( 특히 읽기 수가 쓰기 수보다 훨씬 큰 경우).Scenarios where performance of data reads must be fine tuned separately from performance of data writes, especially when the number of reads is much greater than the number of writes. 이 시나리오에서는 읽기 모델을 확장할 수 있지만 몇 가지 인스턴스에서만 쓰기 모델을 실행할 수 있습니다.In this scenario, you can scale out the read model, but run the write model on just a few instances. 소수의 쓰기 모델 인스턴스는 병합 충돌 발생을 최소화하는 데도 기여합니다.A small number of write model instances also helps to minimize the occurrence of merge conflicts.

  • 개발자 중 한 팀은 쓰기 모델에 포함되는 복잡한 도메인 모델에 집중하고 또 한 팀은 읽기 모델과 사용자 인터페이스에 집중할 수 있는 시나리오.Scenarios where one team of developers can focus on the complex domain model that is part of the write model, and another team can focus on the read model and the user interfaces.

  • 시스템이 시간이 지나면서 진화할 것으로 예상되어 여러 버전의 모델을 포함할 수 있거나 비즈니스 규칙이 정기적으로 변하는 시나리오Scenarios where the system is expected to evolve over time and might contain multiple versions of the model, or where business rules change regularly.

  • 특히 이벤트 소싱과 조합해 다른 시스템과 통합하는 경우. 이때 하위 시스템 하나의 일시적인 장애가 다른 시스템의 가용성에 영향을 주지 않아야 합니다.Integration with other systems, especially in combination with event sourcing, where the temporal failure of one subsystem shouldn't affect the availability of the others.

다음과 같은 경우 이 패턴은 권장되지 않습니다.This pattern isn't recommended when:

  • 도메인 또는 비즈니스 규칙은 간단합니다.The domain or the business rules are simple.

  • 간단한 CRUD 스타일 사용자 인터페이스와 데이터 액세스 작업만으로도 충분합니다.A simple CRUD-style user interface and data access operations are sufficient.

가장 가치 있는 시스템의 제한된 구역에 CQRS 적용을 고려해야 합니다.Consider applying CQRS to limited sections of your system where it will be most valuable.

이벤트 소싱 및 CQRSEvent Sourcing and CQRS

CQRS 패턴은 이벤트 소싱 패턴과 함께 사용되는 경우가 많습니다.The CQRS pattern is often used along with the Event Sourcing pattern. CQRS 기반 시스템은 별도의 읽기 및 쓰기 데이터 모델을 사용하며 각각 관련 작업에 맞춤화되고 종종 물리적으로 분리된 저장소에 배치됩니다.CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically separate stores. 이벤트 소싱 패턴과함께 사용하면 이벤트 저장소가 쓰기 모델이며 정보의 공식 소스입니다.When used with the Event Sourcing pattern, the store of events is the write model, and is the official source of information. 보통 CQRS 기반 시스템의 읽기 모델은 고도로 비정규화된 뷰의 형태로 데이터의 구체화된 뷰를 제공합니다.The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views. 이러한 뷰는 애플리케이션의 인터페이스 및 디스플레이 요구 사항에 맞춤화되어 디스플레이 및 쿼리 성능을 모두 최대화하는 데 기여합니다.These views are tailored to the interfaces and display requirements of the application, which helps to maximize both display and query performance.

특정 시점의 실제 데이터 대신 이벤트의 스트림을 쓰기 저장소로 사용하면 단일 집계에서 업데이트 충돌을 방지하고 성능과 확장성을 최대화할 수 있습니다.Using the stream of events as the write store, rather than the actual data at a point in time, avoids update conflicts on a single aggregate and maximizes performance and scalability. 읽기 저장소를 채우는 데 사용하는 데이터의 구체화된 뷰를 비동기적으로 생성하는 데 이벤트를 사용할 수 있습니다.The events can be used to asynchronously generate materialized views of the data that are used to populate the read store.

이벤트 저장소는 정보의 공식적인 출처이기 때문에, 시스템이 진화하거나 읽기 모델을 변경해야 할 때 구체화된 뷰를 삭제하고 모든 지난 이벤트를 재생해 현재 상태의 새로운 표현을 생성할 수 있습니다.Because the event store is the official source of information, it is possible to delete the materialized views and replay all past events to create a new representation of the current state when the system evolves, or when the read model must change. 사실상 구체화된 뷰는 데이터의 지속형 읽기 전용 캐시입니다.The materialized views are in effect a durable read-only cache of the data.

CQRS를 이벤트 소싱 패턴과 함께 사용할 때는 다음을 고려해야 합니다.When using CQRS combined with the Event Sourcing pattern, consider the following:

  • 쓰기 및 읽기 저장소가 분리되는 시스템처럼 이 패턴을 기반으로 하는 시스템만이 결과적으로 일관성을 유지할 수 있습니다.As with any system where the write and read stores are separate, systems based on this pattern are only eventually consistent. 생성되는 이벤트와 업데이트되는 데이터 저장소 사이에는 약간의 지연이 나타나게 됩니다.There will be some delay between the event being generated and the data store being updated.

  • 이벤트를 시작하고 처리하며 쿼리나 읽기 모델에 필요한 적절한 뷰 또는 개체를 어셈블하거나 업데이트하는 코드를 생성해야 하기 때문에, 이벤트 소싱 패턴은 더 복잡합니다.The pattern adds complexity because code must be created to initiate and handle events, and assemble or update the appropriate views or objects required by queries or a read model. CQRS 패턴을 이벤트 소싱 패턴과 함께 사용하는 경우 패턴이 복잡하기 때문에 성공적으로 구현하는 것이 더 어려워질 수 있으므로 시스템 디자인에 대한 다른 접근 방식이 필요합니다.The complexity of the CQRS pattern when used with the Event Sourcing pattern can make a successful implementation more difficult, and requires a different approach to designing systems. 그러나 이벤트 소싱은 도메인을 더 쉽게 모델링할 수 있고 데이터를 변경한 의도가 보존되기 때문에 뷰를 다시 작성하거나 새로 만들기가 더 쉽습니다.However, event sourcing can make it easier to model the domain, and makes it easier to rebuild views or create new ones because the intent of the changes in the data is preserved.

  • 특정 엔터티 또는 엔터티 모음을 위한 이벤트를 재생하고 처리하여 데이터의 읽기 모델 또는 프로젝션에 사용할 구체화된 뷰를 생성하려면 상당한 처리 시간과 리소스 사용이 필요할 수 있습니다.Generating materialized views for use in the read model or projections of the data by replaying and handling the events for specific entities or collections of entities can require significant processing time and resource usage. 장기간 값의 합계 또는 분석이 필요한 경우에 특히 그런데 그 이유는 관련된 모든 이벤트를 검사해야 하기 때문입니다.This is especially true if it requires summation or analysis of values over long periods, because all the associated events might need to be examined. 이 문제는 발생한 특정 동작의 총 개수 또는 엔터티의 현재 상태와 같이 예약된 간격으로 데이터의 스냅샷을 구현해 해결할 수 있습니다.Resolve this by implementing snapshots of the data at scheduled intervals, such as a total count of the number of a specific action that have occurred, or the current state of an entity.

예제Example

다음 코드는 읽기 모델과 쓰기 모델에 다른 정의를 사용하는 CQRS 구현의 예제 중 일부를 보여 줍니다.The following code shows some extracts from an example of a CQRS implementation that uses different definitions for the read and the write models. 모델 인터페이스는 기본 데이터 저장소의 기능을 지정하지 않고 진화할 수 있으며 분리되기 있기 때문에 독립적으로 세밀하게 조정할 수 있습니다.The model interfaces don't dictate any features of the underlying data stores, and they can evolve and be fine-tuned independently because these interfaces are separated.

다음 코드는 읽기 모델 정의를 보여줍니다.The following code shows the read model definition.

// Query interface
namespace ReadModel
{
  public interface ProductsDao
  {
    ProductDisplay FindById(int productId);
    ICollection<ProductDisplay> FindByName(string name);
    ICollection<ProductInventory> FindOutOfStockProducts();
    ICollection<ProductDisplay> FindRelatedProducts(int productId);
  }

  public class ProductDisplay
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public decimal UnitPrice { get; set; }
    public bool IsOutOfStock { get; set; }
    public double UserRating { get; set; }
  }

  public class ProductInventory
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public int CurrentStock { get; set; }
  }
}

시스템에서 사용자가 제품을 평가하는 것을 허용합니다.The system allows users to rate products. 애플리케이션 코드는 다음 코드에 제시된 RateProduct 명령을 사용하여 제품을 평가합니다.The application code does this using the RateProduct command shown in the following code.

public interface ICommand
{
  Guid Id { get; }
}

public class RateProduct : ICommand
{
  public RateProduct()
  {
    this.Id = Guid.NewGuid();
  }
  public Guid Id { get; set; }
  public int ProductId { get; set; }
  public int Rating { get; set; }
  public int UserId {get; set; }
}

시스템이 ProductsCommandHandler 클래스를 사용하여 애플리케이션이 전송한 명령을 처리합니다.The system uses the ProductsCommandHandler class to handle commands sent by the application. 일반적으로 클라이언트는 큐와 같은 메시징 시스템을 통해 명령을 도메인에 보냅니다.Clients typically send commands to the domain through a messaging system such as a queue. 명령 처리기는 이러한 명령을 수락하고 도메인 인터페이스의 메서드를 호출합니다.The command handler accepts these commands and invokes methods of the domain interface. 요청이 충돌할 가능성이 줄어들도록 세분화된 각 명령이 디자인됩니다.The granularity of each command is designed to reduce the chance of conflicting requests. 다음 코드는 ProductsCommandHandler 클래스의 개요를 보여 줍니다.The following code shows an outline of the ProductsCommandHandler class.

public class ProductsCommandHandler :
    ICommandHandler<AddNewProduct>,
    ICommandHandler<RateProduct>,
    ICommandHandler<AddToInventory>,
    ICommandHandler<ConfirmItemShipped>,
    ICommandHandler<UpdateStockFromInventoryRecount>
{
  private readonly IRepository<Product> repository;

  public ProductsCommandHandler (IRepository<Product> repository)
  {
    this.repository = repository;
  }

  void Handle (AddNewProduct command)
  {
    ...
  }

  void Handle (RateProduct command)
  {
    var product = repository.Find(command.ProductId);
    if (product != null)
    {
      product.RateProduct(command.UserId, command.Rating);
      repository.Save(product);
    }
  }

  void Handle (AddToInventory command)
  {
    ...
  }

  void Handle (ConfirmItemsShipped command)
  {
    ...
  }

  void Handle (UpdateStockFromInventoryRecount command)
  {
    ...
  }
}

이 패턴을 구현할 때 유용한 패턴 및 지침은 다음과 같습니다.The following patterns and guidance are useful when implementing this pattern:

  • Data Consistency Primer(데이터 일관성 입문서).Data Consistency Primer. CQRS 패턴을 사용할 때 읽기 및 쓰기 데이터 저장소 간의 결과적 일관성 때문에 일반적으로 발생하는 문제와 이러한 문제의 해결 방법을 설명합니다.Explains the issues that are typically encountered due to eventual consistency between the read and write data stores when using the CQRS pattern, and how these issues can be resolved.

  • 데이터 분할 지침.Data Partitioning Guidance. 데이터를 확장성을 개선하고 경합을 줄이며 성능을 최적화하기 위해 데이터를 별도로 관리하고 액세스할 수 있는 파티션으로 나누는 모범 사례를 설명합니다.Describes best practices for dividing data into partitions that can be managed and accessed separately to improve scalability, reduce contention, and optimize performance.

  • 이벤트 소싱 패턴.Event Sourcing pattern. 이벤트 소싱을 CQRS 패턴과 함께 사용하여 복잡한 도메인의 작업을 간소화하면서 성능, 확장성 및 응답성을 향상시킬 수 있는 방법을 자세히 설명합니다.Describes in more detail how Event Sourcing can be used with the CQRS pattern to simplify tasks in complex domains while improving performance, scalability, and responsiveness. 또한 트랜잭션 데이터의 일관성을 제공하면서 보상 동작을 가능하게 하는 전체 감사 내역과 기록을 유지하는 방법도 설명합니다.As well as how to provide consistency for transactional data while maintaining full audit trails and history that can enable compensating actions.

  • 구체화된 뷰 패턴.Materialized View pattern. CQRS를 구현한 읽기 모델은 쓰기 모델 데이터의 구체화된 뷰를 포함할 수 있습니다. 또는 구체화된 뷰를 생성하는 데 읽기 모델을 사용할 수 있습니다.The read model of a CQRS implementation can contain materialized views of the write model data, or the read model can be used to generate materialized views.

  • 패턴 및 사례 가이드 CQRS 과정.The patterns & practices guide CQRS Journey. 특히 명령 쿼리 책임 분리 패턴을 소개하면 패턴과 유용한 시기를 탐색하고 에필로그: 학습한 교훈은 이 패턴을 사용할 때 발생한 몇 가지 문제를 이해하는 데 도움이 됩니다.In particular, Introducing the Command Query Responsibility Segregation pattern explores the pattern and when it's useful, and Epilogue: Lessons Learned helps you understand some of the issues that come up when using this pattern.

  • Martin Fowler의 CQRS 게시물. 패턴의 기본 내용을 설명하고 다른 유용한 리소스에 연결되는 링크를 제공합니다.The post CQRS by Martin Fowler, which explains the basics of the pattern and links to other useful resources.