cqrs, islandsofdata.. Methodoloy

프로젝트 아키텍처 cqrs로 확정.

CQRS ref Martin Fowler Bliki
ElegantCode 스케치를 보면 이해가 쉽다.


프로젝트 내용인 즉..
  • 여러회사들로 부터 몇몇 업무에 대한 데이터를 받아 집적.
  • 데이터에 대한 특정 판단기준에 의해 리포트, 데이터서비스 제공
  • 데이터 서비스에 대한 통계
집적과 데이터서비스로 분리되어 있고 수행시점 또한 다르다.
조직도 집적조직(전환,인터페이스,집적)과 데이터서비스조직(조회,리포트,통계)으로 분리
robustness정의 시점에 command, query 패키지 분리하고 cqrs원칙 공유정도로 간단히 정리되었다.

다른 메커니즘은 별도로 분리하는게 당연..
command와 query 또한 같은 선상에 있는 것인데 
고정관념에 빠져있어서인지 선뜻 걸음을 내딛기가 꺼려졌던 듯.

주로 islandsofdata 원리를 우선적으로 적용하고 
해당원리를 벗어나는 경우 island 범위를 넓혀가는 방식으로 접근했지만
사실은 islandofdata를 벗어날 수 밖에 없는 내용은 별도의 메커니즘, 원리로 일반화시켰어야 했다.
모델내에 해당 메커니즘을 위한 공간을 만들어 모델로 유지되었어야 할 내용.

이번 프로젝트가 끝나면 조금은 더 자신있게 이런저런 곳에 cqrs를 적용할 수 있을 듯..


[참고. cqrs확정까지..]
시스템요구사항 세션중에 수행팀에서 개념적으로 둘을 분리했으면 한다고 말해왔고
아키텍처 어쩌고 거창하게 거들먹거릴 필요없이 요청내용이 정리되서 자연스레 결정된 결과가 cqrs.
아키텍처 정의란 적용할 논리를 정의하는게 아니라, 필요한 논리를 도출하는 것이란 것을 다시한번 실감.

[참고이미지] 
친숙한 islandsofdata 개념 (ref. business component factory written by oliver sims).

핑백

  • 상실의시대 : CQRS에 대한 단상(1) 2019-11-13 19:46:59 #

    ... 으로 예를든다면 데이터를 집적한 뒤 조회 서비스를 제공하는 보험 개발원이나 손해보험협회 같은 비즈니스가 CQRS에 적합하다. 개인적으로 2011년에 20여명으로 구성된 소규모 프로젝트에서 적용했는데 도메인 자체가 집적/조회로 구분되어 있어 이슈없이 모델을 분할했고 무난히 완료했다그 외엔 조회에 대한 요건이 집적모델을 ... more

덧글

댓글 입력 영역