정적 팩토리 메서드의 장점은 다음과 같다.
롬복에서도 RequiredArgsConstructor.staticName으로 정적 팩토리 메서드를 만들 수 있다.
CQRS에 대한 마틴 파울러의 글 참고
https://martinfowler.com/bliki/CQRS.html
Command와 Query의 책임 분할을 지향하는 패턴이다.
정보를 업데이트 할 때와 조회할 때 다른 모델을 사용하는 것이 가장 핵심이다.
대부분의 경우에는 CQRS를 적용하면 복잡성이 높아지는 위험성이 있다.
보통은 CRUD 저장소를 이용하는 것이 일반적이다. 우리가 레코드를 읽고, 쓰고, 업데이트, 삭제하는 레코드 구조 모델이 있다.
요구사항이 복잡해질수록 모델에서 점점 멀어진다.
레코드들을 하나로 합치거나, 여러 정보를 결합해서 가상의 레코드를 형성하는 것 처럼 다른 방식으로 정보를 가져오고 싶을 수 있다.
업데이트의 경우, 특정 데이터의 조합만을 저장하거나, 제공한 방식과 다르게 전달되는 데이터에 대한 validation 조건을 추가할 수 있다.
우리가 도메인 모델을 사용하는 경우, 모델이라는 것은 도메인을 개념적으로 표현한 것이 되고, 영구 저장소(DB)도 개념적 모델에 가능한 가깝게 만든다.
하지만 이 도메인 모델은 요구사항의 변화나 확장에 따라서 점점점 거대해지거나 변질될 수 있다.
CQRS는 개념적 모델을 업데이트와 읽기로 나누는 방식을 제시한다.
우리가 데이터베이스로부터 데이터를 읽어오고 처리를 하게 되면, 이미 그 사이에 데이터가 변경되었을 가능성이 높다. 데이터베이스 상의 동일 데이터에 여러 사용자가 동시에 접근하는 사례가 많을 경우, 예상치 못한 결과를 야기할 수 있다. 그래서 CRUD 중 CUD와 R을 구분해서 사용하여 이와같은 문제 발생을 줄일 수 있다.
대부분의 정보 시스템은 CRUD 모델에도 충분히 문제없다. 오히려 더 적합하다고 할 수있다. CQRS 패턴을 코드에 적용하는데는 많은 소요가 들어가고, 때문에 무조건적으로 적용하는 것은 옳지않으며 신중해야한다.
도메인 주도 설계. 도메인 패턴을 중심에 높고 설계하는 방식.
비즈니스 도메인 내에서 일어나는 일들을 찾아 Bounded Context를 식별하는 방법론
비즈니스 도메인 내에서 발생하는 모든 이벤트를 과거형으로 기술.