|
Size: 1497
Comment:
|
Size: 1760
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 15: | Line 15: |
| [[https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs|Microsoft의 CQRS 문서]] 참고. | [[https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs|Microsoft의 CQRS 문서]] 참고. [[https://www.popit.kr/cqrs-eventsourcing/|Popit에 게제된 글]]도 읽어볼만하다. RDBMS와 NoSQL을 hybrid로 사용해서, command는 RDB에 대해서, read는 NoSQL에서 한다는 발상이 독특했다. RDBMS to NoSQL sync는 어떻게 유지하지? |
Command and Query Responsibility Segregation
명령과 쿼리의 권한 분리.
DB나 상태를 변화(mutate)시키는 '명령(command)'과, 조회만 하는 '쿼리(query)'를 분리하자는 이야기.
변화시키는 요청은, Queue 같은 곳에 command를 발행하고, worker가 받아서 command를 실행하면서 수정을 처리.
조회하는 요청은 DB에서 직접 끌어와서 처리.
장점은?
우선, Event Source pattern을 위해서는 CQRS가 필수적이라는 의견.
Microsoft의 CQRS 문서 참고. Popit에 게제된 글도 읽어볼만하다. RDBMS와 NoSQL을 hybrid로 사용해서, command는 RDB에 대해서, read는 NoSQL에서 한다는 발상이 독특했다. RDBMS to NoSQL sync는 어떻게 유지하지?
애초에 CQRS가 궁금했던게, SQS + Lambda를 기반으로 하는, event sourcing pattern으로 시스템을 구성할 수는 없을까 했었다.
Web API에서는 그냥 간단하게 SQS에 command message만 발행하고, 뒷단에서 lambda가 받아서 수정을 처리하는.
command는 event sourceing pattern으로 한다 하더라도, query는 예전처럼 동기 방식으로 구현해야 할듯.
이슈/문제는?
이를테면 DeepNatural AI 플랫폼에서 task assign하는 로직 같은 경우, 곧바로 assign에 대한 처리 결과가 필요한데, 이것은 어떻게 하나? 요청에 uuid를 발급하고, 그 uuid로 처리 결과를 조회하도록?
- command들 간에 연관이 필요한 경우? 한 command가 너무 복잡한 경우, sub command들의 composition으로 구성해야 하나?