[클린 아키텍처 04] 유스케이스 구현하기

<< 클린 아키텍처 04 >>

유스케이스 구현하기

유스케이스 둘러보기

유스케이스를 구성하는 단계는 다음과 같다. 

 

1. 입력을 받는다

2. 비즈니스 규칙을 검증한다.

3. 모델 상태를 조작한다.

4. 출력을 반환한다.

 

입력 유효성 검증

입력 유효성 검증은 어디에서 해야하는가? 바로 입력 모델이다.

input parameter로 들어오는 모델(입력 모델)에서 입력 유효성 검증을 수행한다.

해당 모델의 위치는 use case의 위치와 같다! because use case api의 일부이기 때문에!

 

@Value
@EqualsAndHashCode(callSuper = false)
public
class SendMoneyCommand extends SelfValidating<SendMoneyCommand> {

    @NotNull
    private final AccountId sourceAccountId;

    @NotNull
    private final AccountId targetAccountId;

    @NotNull
    private final Money money;

    public SendMoneyCommand(
            AccountId sourceAccountId,
            AccountId targetAccountId,
            Money money) {
        this.sourceAccountId = sourceAccountId;
        this.targetAccountId = targetAccountId;
        this.money = money;
        this.validateSelf();
    }
}

 

비즈니스 규칙 검증하기

예를 들어 '출금 계좌는 초과인출 되어서는 안된다!' 라는 규칙이 있을 경우 해당 검증 로직을 어디에 넣어야 할까?

두 가지 케이스가 가능하다. 

 

1) 도메인 엔티티 안에 넣는 경우

위치를 정하기도 쉽고, 추론하기도 쉽다

 

2) 유스케이스 코드에서 엔티티를 사용하기 전에 넣는 경우

 

하지만 도메인 모델을 로드해서 사용해야 하는 경우엔 도메인 엔티티 안에 넣자

 

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

풍부한 도메인 모델은?

애플리케이션 코어에 있는 엔티티에서 많은 도메인 로직이 구현된다. -> 유스케이스가 엔티티에 위치

 

빈약한 도메인 모델은?

엔티티에는 Getter, Setter 정도만 존재한다. -> 도메인 로직이 유스케이스 클래스에 구현되어 있다

 

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

출력도 가능한 각 유스케이스에 맞게 구체적일수록 좋다

유스케이스들 간에 같은 출력 모델을 공유하게 되면 유스케이스들도 강하게 결합된다

 

유스케이스별로 잘 분리해서 구현하면 유지보수가 쉽다