TIL

04. 유스케이스 구현하기

• 육각형 아키텍처는 도메인 중심 아키텍처에 적합하다.
  • DDD를 할 수도 있고 풍부하거나 빈약한 도메인 모델을 구현할 수도 있다.

도메인 모델 구현하기

• 한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현해보자.
• Account 코드
  • Aoount 엔티티는 실제 계좌의 현재 스냅숏을 제공
  • 계좌에 대한 모든 입금과 출금은 Activity 엔티티에 포착된다.
  • Account 엔티티는 ActivityWindow 값 객체에서 포착한 몇 주간의 범위에 해당하는 활동만 보유한다.
  • Account 엔티티는 ActivityWindow의 첫 번째 활동 전 잔고를 표현하는 baselineBalance 필드를 가진다. (총 잔고는 baselineBalance + ActivityWindow의 모든 잔고를 합한 값)
  • withdraw()와 deposit() 메서드로 입금과 출금의 활동들을 활동창에 추가할 수 있다.

유스케이스 둘러보기

• 일반적으로 유스케이스는 다음 단계를 따른다.
  • 입력을 받는다
  • 비즈니스 규칙을 검증한다
  • 모델 상태를 조작한다
  • 출력을 반환한다
• 유스케이스 코드는 도메인 로직만 신경쓴다
  • 입력 유효성 검증으로 오염되면 안 된다
  • 비즈니스 규칙만 검증하면 된다. (이 책임을 도메인과 공유)
• SendMoneyService 코드
  • SendMoneyService는 SendMoneyUseCase를 구현
  • 계좌 조회를 위해 아웃고잉 포트 인터페이스인 LoadAccountPort 호출
  • 계좌 상태 업데이트를 위해 UpdateAccountStatePort 호출

입력 유효성 검증

• 입력 유효성 검증은 유스케이스 클래스 책임은 아니지만 애플리케이션 계층의 책임에 해당하긴 하다
  • 애플리케이션 계층에서 입력 유효성을 검증하지 않으면 애플리케이션 코어 외부에서 유효하지 않은 입력을 받게 되고 모델의 상태를 해칠 수 있다.
• 입력 모델(input model)에서 입력 유효성을 검증할 수 있다.
  • SendMoneyCommand 코드
  • Bean Validation API로 Null 체크

생성자의 힘

• 소프트웨어 생명 주기에서 입력 값의 변화는 자주 있는 일이다.
  • SendMoneyCommand의 파라미터 수가 변화
• 파라미터가 많다고 해서 빌더 패턴을 사용하면 컴파일 타임에 휴먼 미스를 잡을 수가 없다.
  • 런타임에 예외가 발생할 수도 있지만 말이다.
• 생성자를 사용하면 새로운 필드를 추가하거나 삭제할 때 컴파일 에러를 통해 코드 변경사항을 반영할 수 있다.
  • 요즘 IDE에서는 긴 파라미터 리스트도 깔끔하게 포메팅할 수 있다.

유스케이스마다 다른 입력 모델

• 각기 다른 유스케이스에 동일한 입력 모델을 사용하고 싶을 때가 있다.
  • 입력 받는 값이 비슷할 때
  • ‘계좌 등록하기’와 ‘계좌 업데이트하기’ 모두 동일한 정보가 필요
• 결론적으로 각 유스케이스 전용 입력 모델을 사용해야 한다.
  • 다른 유스케이스와의 결합도 제거를 통해 부수효과 방지
  • 비슷해 보이지만 각기 다른 검증 로직을 거쳐야 할 때가 많다.

비즈니스 규칙 검증하기

• 입력 유효성 검증과 비즈니스 규칙의 큰 차이는 도메인 모델의 현 상태에 접근할 필요가 있냐 없냐이다.
  • 입력 유효성은 구문상의 유효성을 검증
    • ex) 금액은 0보다 커야한다.
  • 비즈니스 규칙은 유스케이스 맥락 속의 의미적인 유효성을 검증
    • ex) 출금 계좌는 초과 출금되어서는 안 된다. (모델의 현재 상태에 접근해야 함)
• 비즈니스 규칙은 유스케이스에서 검증할 수 있다.

• 비즈니스 규칙 검증의 가장 좋은 방법은 도메인 엔티티 안에 작성하는 것이다.

    public class Account {
      
        // ...
      
        public boolean withdraw(Money money, AccountId targetAccountId) {
            if (!mayWithdraw(money)) {
                return false;
            }
            // ...
      
            return true;
        }
  

• 도메인 엔티티에서 규칙을 검증하기 어려운 경우 유스케이스 코드에서 도메인 엔티티를 사용하기 전에 해도 된다.

유스케이스마다 다른 출력 모델

• 입력 모델과 비슷하게 유스케이스에 맞게 출력 모델도 구체적일수록 좋다.
  • 유스케이스 간 출력 모델을 공유하게 되면 장기적으로 결합을 발생시키고 부수효과를 발생시킨다.
• 위 예제에서는 boolean 값 하나를 반환했는데 이 맥락에서 반환할 수 있는 가장 구체적인 최소한의 값이다.
  • 정답은 없지만 가능한 적게 반환하자

읽기 전용 유스케이스

• ‘계좌 잔고 보여주기’ 같은 조회만 수행하는 유스케이스가 존재한다.
• 이를 구현하는 한 가지 방법은 쿼리를 위한 인커밍 전용 포트를 만들고 이를 쿼리 서비스에서 구현하는 것이다.
• 이러한 개념은 CQS, CQRS 같은 개념과 잘 맞는다.