position이 다른 모듈과 상호작용해야 하는 상황이 많다.
- 예를 들어, 스코어보드를 보여주기 위해 우승자의 정보(이름, position)를 외부의 시스템(DB, API 등)에 기록해야 하는 요구사항이 생겼다면 이를 처리하기 위해 position에 접근이 필요한 경우가 생길 수 있습니다. 인터페이스로 분리해서 의존 관계를 역전시키면 getter 없이도 처리할 수는 있겠지만 합리적이지는 않다고 생각해요.
- 마찬가지로 한 도메인 모델이 다른 도메인 모델과 상호작용해야 하는 경우도 발생할 수 있습니다(사용자를 생성할 때 이름이 중복돼선 안된다는 규칙이 있다면, 이걸 사용자 모델 내에서 처리하기는 쉽지 않겠죠?).
- 위와 같은 케이스가 도메인 모델의 외부에서 일정한 비지니스 로직을 처리해야 하는 경우인데요. 이런 경우가 흔하게 발생하기 때문에 이를 다루는 방법들도 여러가지가 있는데요. 이후에 공부하실 기회가 있겠지만, 미리 관심이 있으시다면 계층형 아키텍처(layered architecture)라는 키워드나 PoEAA라는 책의 서비스(service) 항목을 살펴보시면 좋을 것 같네요.
학습동기
- getter를 안쓰고 어떻게 구현해야하나 고민하던중, 리뷰어 에단이 계층형 아키텍처를 이용해 도메인 로직을 외부에서 다루는 방법을 제안했다.
- 매 경기 결과값을 출력해야 하는데, 도메인에서 출력하는 기능을 담당하는 건 과도한 책임이다. view에 안전하게 넘겨주기 위해서 Dto를 도입했다.
계층형 아키텍처(Layered Architecture)
- Presentation 계층
- 사용자와 상호 작용 처리 계층
- CLI, HTTP 요청, HTML 처리 등을 담당한다.
- 하위 계층에서 발생하는 Exception이나 Error에 대한 처리를 맡는다.
- 흔히 말하는 MVC (Model / View / Controller) 도 이 계층에 속한다. - Domain(Business or Service) 계층
- 서비스/시스템의 핵심 로직
- 유효성 검사 및 계산을 포함하는 Business 논리 계층
- 애플리케이션이 수행해야하는 도메인과 관련된 작업들을 담당한다.
- 입력/저장된 데이터를 기반으로 계산
- Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사 - Data Access(Persistence) 계층
- DAO 계층
- 데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층 - DTO는 기능이 제한된 도메인 객체, 혹은 View 전용 등의 도메인과 무관하게 데이터 전달만을 위한 객체를 뜻한다.
위와 같이 계층을 분리하는 이유는 간단하다. 한 곳에서 위의 모든 작업이 한꺼번에 이루어진다면
- 코드의 복잡성 증가,
- 유지보수의 어려움과 유연성 부족,
- 중복 코드의 증가,
- 낮은 확장성
계층화의 핵심은 각 계층은 응집도가 높으면서, 다른 계층과는 낮은 결합도를 가지는데 있다.
DTO
DTO (Data Transfer Object) 는 도메인 객체가 도메인 계층을 벗어나지 못하도록 지원한다.
Presentation 영역에서 필요한 로직과 도메인 로직을 분리할 수 있다.
단순히 화면 노출에 필요한 계산 도메인 로직이 담당할 것이 아니다.
도메인 로직이 오염된다.
도메인 객체는 단순히 값 조작과 연산이 들어가는게 아니라 주요한 도메인 로직을 담고 있다.
이런 경우에는 DTO를 통해 단순히 값만 담은 형태로 제공한다.
프로젝트 적용
view가 경기 결과 출력에 대한 책임을 지려면 OutputView 에서 매 경기마다 결과를 출력할 때 Car의 이름과 현재 위치값을 가져와야하는데 getter를 직접 이용하면 도메인이 오염될 수 있다. 그래서 CarDto 객체를 통해 이름과 위치값을 전달할 수 있도록 활용했다.
Reference
https://walbatrossw.github.io/etc/2018/02/26/etc-layered-architecture.html
https://jojoldu.tistory.com/603
세상을 아름답게!