회사 업무중, DTO가 중첩이 되는 클래스에 대해 개발중, 당연히 공통으로 되는 필드는
extends하여 구성을 하려고 했는데,
TF장님이 CQRS에 대해 언급하였고, 해당 방법에 의해서 각각 나누는것이 좋다고 말씀하셨다.
또한 보면 이해되는 영상을 알려주셔서 해당 영상에 대한 내용중 일부분을 잊어버리지 않도록 작성한다.
Command(명령)
- 시스템 데이터 변경
Query(조회)
- 시스템 데이터 조회
Responsibility(책임)
- 구성 요소의 역할
- 구성 요소 (모델)
Segregation(분리)
- 역할에 따른 구성 요소 분리
명령과 쿼리에 따른 DTO를 분할 시, 코드가 중복되는 부분이 많아 질수 있다. ( 나 또한 중복이 되니까 공통으로 엮을 생각만 한것이고..)
하지만 추후 유지보수나 수정사항에 대해서 명령에만 추가되어야할 필드, 조회에 추가되어야 하는 필드가 나뉘게 되어서 지속적으로 추가가 되면 해당 DTO는 명확한 이름을 가진 모델이 아닌 난잡하게 추가되어 있는 형태가 된다.
즉, 코드에 대한 역할과 책임이 모호해지며, 해당 클래스에 대한 의미가 퇴색되고 수정이 점점 어렵게 될것이다( 코드가 산으로 간다... )
명령과 쿼리는 코드 변경 빈도, 사용자가 다르다. 기능마다 요구하는 성능이 다를것이고, 단일 모델로는 다양한 성능 향상 기법에 대한 적용이 어려울 수 있다.
Search!