유스케이스 둘러보기입력을 받는다입력 유효성 검증유스케이스마다 다른 입력 모델 → 용도별 dto 따로 만드는거!비즈니스 규칙을 검증한다모델 상태를 조작한다풍부한 도메인 모델 vs 빈약한 도메인 모델출력을 반환한다유스케이스마다 다른 출력 모델
- 유스케이스 코드가 도메인 로직에만 신경 써야 하고 입력 유효성 검증으로 오염되면 안된다고 생각함(by 저자)
- 유스케이스는 비즈니스 규칙을 검증할 책임이 있음. 도메인 엔티티와 이 책임을 공유
유스케이스 둘러보기
입력을 받는다
입력 유효성 검증
- 어플리케이션 계층(유스케이스, 엔티티)에서 입력 유효성을 검증해야 하는 이유는 그렇게 하지 않을 경우 애플리케이션 코어의 바깥쪽으로부터 유효하지 않은 입력값을 받게 되고, 모델의 상태를 해칠 수 있기 때문임
- 유스케이스 클래스가 아닌 입력 모델(input model)에서 검증을 하자 → 생성자 내에서 입력 유효성 검증
유스케이스마다 다른 입력 모델 → 용도별 dto 따로 만드는거!
- 유스케이스 전용 입력 모델은 유스케이스를 훨씬 명확하게 만들고 다른 유스케이스와의 결합도 제거해서 불필요한 부수효과 발생하지 않게 함
비즈니스 규칙을 검증한다
- 입력 유효성 검증 vs 비즈니스 규칙 검증
- 도메인 모델의 현재 상태 접근 x 🆚 도메인 모델의 현재 상태 접근 o
- 논쟁의 여지가 있지만, 명확하게 구분할 수 있어서 도움이 됨
- syntatical(구문상) 검증하는 느낌 🆚 semantical(의미적인) 검증하는 느낌
- eg) 출금 계좌는 초과 출금되어서는 안 된다 → 비즈니스 로직 (모델의 현재 상태를 이용하기 때문)
- eg) 송금되는 금액은 0보다 커야 한다 → 모델에 접근하지 않고도 검증될 수 있기에 입력 유효성 검증
- 비즈니스 규칙 검증 구현 어떻게 ? ⇒ 비즈니스 규칙을 도메인 엔티티 안에 넣는 식으로 구현
모델 상태를 조작한다
풍부한 도메인 모델 vs 빈약한 도메인 모델
- 풍부한 도메인 모델에서는 애플리케이션의 코어에 있는 엔티티에서 가능한 한 많은 도메인 로직이 구현됨
- 엔티티들은 상태를 변경하는 메서드를 제공하고 비즈니스 규칙에 맞는 유효한 변경만을 허용함
- ‘빈약한’ 도메인 모델에서는 엔티티 자체가 굉장히 얇다. 일반적으로 엔티티는 상태를 표현하는 필드와 이 값을 읽고 바꾸기 위한 getter, setter 메서드만 포함하고 어떤 도메인 로직도 가지고 있지 않음 ⇒ 도메인 로직이 유스케이스 클래스에 구현돼 있다는 것임(그래서, ‘풍부함'이 엔티티 대신 유스케이스에 존재하는 것)
출력을 반환한다
유스케이스마다 다른 출력 모델
- 입력과 비슷하게 출력도 가능하면 각 유스케이스에 맞게 구체적일수록 좋다
- 출력은 호출자에게 꼭 필요한 데이터만 들고 있어야 한다
- 유스케이스를 가능한 한 구체적으로 유지하기 위해서는 계속 질문해야 하고, 만약 의심스럽다면 가능한 한 적게 반환하자
유스케이스들 간에 같은 출력 모델을 공유하게 되면 유스케이스들도 강하게 결합된다.- 한 유스케이스에서 출력 모델에 새로운 필드가 필요해지면 이 값과 관련이 없는 다른 유스케이스에서도 이 필드를 처리해야 함
- 공유 모델은 장기적으로 봤을 때 갖가지 이유로 점점 커지게 돼 있다
- 물론 이 방법은 유스케이스 간 모델 공유하는 것보다 더 많은 작업이 필요함(유스케이스 별 별도 모델 & 모델 엔티티 매핑..)
- 그러나 유스케이스별 모델 만들면 유스케이스를 명확하게 이해할 수 있고
- 장기적으로는 유지보수하기도 더 쉬움
- 또한 여러 명의 개발자가 다른 사람이 작업 중인 유스케이스를 건드리지 않은 채로 여러 개의 유스케이스를 동시에 작업할 수 있음