이 패턴은 오래된 패턴. 계층형 아키텍처는 각 계층마다 특정 역할 수행하고, 하위에 위치한 계층에만 의존하는 특징.
하위 계층은 상위 계층에 대한 의존성 갖지 않는다. 오직 상위에서 하위로의 의존만 허용.
보통 웹 애플리케이션을 계층형으로 구현할때는 다음 4개의 계층구성을한다.
표현(UI)->응용(서비스)->도메인(모델)->인프라(영속)
- 표현: 유저와 상호작용하는 담당
- 응용: 유저 요청을 실제 처리. 하위 계층 로직들 가져다 쓴다. 서비스 레이어
- 도메인: 도메인 로직 구현. 취소 제약 조건, 상태 변경 등 로직 포함
- 인프라: 디비 연동, 문자 발송. DAO
흩어지는 도메인 로직
도메인 구현에 미숙하고, 도메인 계층 없이 응용과 인프라로만 구현하는 경우가 많다. 단순히 서비스/DAO 로 구성된 계층형 아키텍처를 쓰면 실제로 계층은 3개가 된다. 도메인 영역이 거의 없는 구조에선 도메인 로직이 인프라와 응용으로 분산되는 경향이 있어 코드 유지 보수를 어렵게 하기도 한다.
다음 쿼리는 쿼리에 도메인 로직이 스며들어간 전형적인 예
UPDATE member
SET status = 20
WHERE member_id = ?
AND status = 10이 쿼리는 상태가 10인경우 20으로 바꿈. 이 쿼리 실행하는 코드는 다음과 같은 형태
int cnt = mdao.updateMemberStatus(id);
if(cnt == 0){
//변경건이 없어서 변경 실패 처리
}이 코드에는 어떠한 도메인 로직도 없다. 단지 회원 상태를 변경하는 DAO 메서드를 실행하고 결과 건수가 0이면 변경 실패 처리 한다. 어떤 조건일 때 상태가 변경되는지 확인하려면 쿼리를 뒤져야함.
이것이 바로 도메인 모델이 빈약하거나 없을 때 발생하는 로직 흟어짐 현상.
이렇게 도메인 로직이 쿼리나 컨트롤러 같은 다른 계층에 흩어지는 것을 방지하려면 도메인 로직을 최대한 한 계층으로 모아야 한다.
방법중 하나는 바로 DDD의 전술 패턴을 쓰는것.