CH04 유스케이스 구현하기

입력 유효성 검증은 어디에서 해야할까

먼저 비즈니스 규칙 검증과 입력 유효성 검증은 다른 것이다. 입력 유효성이란 입력 자체에 대한 상식적이지 않은 위반된 것을 의미한다. 예를 들어 Query, Command 객체의 완성도를 이야기한다. 책에서는 이를 유스케이스에서 하면 안되고 Query, Command 의 생성자에서 담당하라고 말하고 있다.

풍부한 도메인 모델 vs 빈약한 도메인 모델

이건 나도 예제 코드를 구현 하면서 고민이 되었던 부분인데 책에서도 명확하게 답을 내리고 있지는 않다. 이 소제목에서 다루는 내용의 핵심은 '비즈니스 규칙을 유스케이스에서 다룰지, 제일 내부의 도메인 객체에서 다룰지' 에 관한 이야기이다.

나는 되도록이면 유스케이스는 도메인 객체의 로직을 호출하는 위임자로만 사용하고 최대한 비즈니스 규칙은 도메인 객체에 넣어 두는게 더 좋은 것 같은데 책에서는 '각자의 필요에 맞는 스타일을 자유롭게 선택' 하라고 한다.

재미있는건 라인의 포스팅에서도 아래와 같은 내용이 있다.

지속 가능한 소프트웨어 설계 패턴: 포트와 어댑터 아키텍처 적용하기LINE ENGINGEERING

패키지 구조에서 domain엔 주로 업무 로직을 포함하는 클래스들이 들어섭니다. application은 주로 유스케이스(usecases)가 작성된 클래스를 포함합니다. 이 계층엔 업무 로직이 거의 없고, domain의 여러 업무 로직을 조합하는 역할을 합니다. interfaces는 클라이언트와 약속한 통신 방식의 어댑터를 포함합니다.

'이 계층엔 업무 로직이 거의 없고' 라고 하는데 완전히 없다고 단정짓지는 않고 있다. 약간 애매한 영역인 것 같은데, 일단 라인의 포스팅 내용은 내가 추구하는 바와 같은 것 같다.

CQRS 적용

책의 샘플 코드에는 언급만 되어 있지 실제로 반영은 되어 있지 않아서 나는 이를 반영했다. 패키지 구조를 다시 보자.

port 에서 query와 command 로 해당 작업이 데이터를 변경하는 의도인지 조회가 의도인지 구분해두었다. 유스케이스 설계 자체가 아키텍처만 봐도 기능을 파악할 수 있다는 장점이 있는데, 이걸 더 자세히 파악(단순 쿼리인지 DML 도 발생하는지) 하는데 도움이 될 수 있기 때문에 패키지를 저렇게 나눴다.