Chapter 6. 응용서비스와 표현 영역
생성일
2024년 2월 22일 오후 9:42
태그
비어 있음
💭 표현 영역과 응용 영역
응용 영역과 표현 영역이 사용자와 도메인을 연결해 주는 매개체 역할을 한다.
표현 영역
응용 서비스에 필요한 데이터 형식이 사용자로부터 전달 받은 데이터 형식과 일치하지 않기 때문에 응용 서비스가 요구하는 형식으로 사용자 요청을 변환한다.
표현 영역의 역할
사용자가 시스템을 사용할 수 있는 화면을 제공하고 제어
사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공
사용자의 세션을 관리
응용 서비스
도메인 객체를 사용해서 사용자가 요청한 기능을 실행한다.
도메인 객체 간 흐름을 제어하기 때문에 단순한 형태를 갖는다.
응용 서비스가 복잡하다면 응용 서비스에서 도메인 로직의 일부를 구현하고 있을 가능성이 높다.
트랜잭션 처리를 담당한다.
도메인 로직을 구현하지 않는다.
why?
도메인 영역과 응용 서비스에 도메인 로직을 분산해 구현하면 코드 품질에 문제가 발생
코드의 응집성이 떨어짐 : 도메인 로직을 파악하기 위해 여러 영역 분석
여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아짐
⇒ 결과적으로 코드 변경을 어렵게 만들어 소프트웨어의 가치를 떨어트림.
💭 응용 서비스 구현
응용 서비스를 구현할 때 몇 거지 고려할 사항과 트랜잭션과 같은 구현 기술의 연동을 알아본다.
응용 서비스의 크기
응용 서비스 구현 방식
한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하기
ex) MemberService에서 회원가입, 비밀번호 변경, 비밀번호 초기화, 회원탈퇴 다 구현
장점 : 코드 중복 제거
단점 : 한 서비스 클래스의 크기가 커져서 코드 품질을 낮추게 된다.
클래스의 크기가 클 때 단점 :연관성이 적은 코드들이 뒤섞여 코드 이해에 방해됨
분리가 좋은 상황임에도 습관적으로 기존 클래스에 추가하게 됨
구분되는 기능별로 응용 서비스 클래스를 따로 구현하기
ex) 암호 변경 기능만을 위한 응용 서비스 클래스를 별도로 구현
장점 : 각 클래스별로 필요한 의존 객체만 포함해 다른 기능을 구현한 코드에 영향을 받지 않음
💡
어떻게 분리하면 좋을까?
서비스 클래스별로 추상화 수준이 달라지는 문제는 없을까?
응용 서비스의 인터페이스와 클래스
응용 서비스를 구현할 때 인터페이스가 늘 필요할까?
인터페이스가 필요한 몇 가지 상황
구현 클래스가 여러 개인 경우
런타임에 구현 객체를 교체해야 할 때
⇒ 하지만 드믈다.
소스 파일이 많아지고 갑접 참조 증가로 젠체 구조가 복잡해진다.
따라서 인터페이스가 명확하게 필요하기 전까지는 응용 서비스에 대한 인터페이스를 작성하는 것이 좋은 선택이라고 볼 수는 없다.
메서드 파라미터와 값 리턴
응용 서비스의 메서드는 가능을 실행하기 위해 필요한 값을 파라미터로 전달받아야 한다.
(개별 파라미터, dto)
스프링 MVC와 같은 웹프레임워크는 웹 요청 파라미터를 자바 객체로 변환하는 기능을 제공
6.1에 나오는 서블릿과 6.3에 나오는 MVC
응용 서비스의 결과를 표현 영역에서 사용할 때
응용 서비스가 리턴한 결과를 사용하여 알맞은 결과를 보여준다.
애그리트를 그래도 리턴한다면?
Java
복사
//모델에 담아 리턴
modelMap.setAttrivute("orderNo", orderNo.toString());
//애그리거트를 그대로 리턴
return order
HTML
복사
<!--표현 영역-->
<a th:href="@{/orders/my{ordNo}(ordNo=${order.number})}">주문 내용 보기</a>
도메인 로직 실행을 응용 서비스와 표현 영역 두 곳에서 할 수 있게됨
코드 응집도를 낮춤
표현 영역에 의존하지 않기
응용서비스에서 표현 영역의 기술을 사용하지 않기
서비스 메서드의 파리미터와 리턴 타입으로 표현 영역의 구현 기술 사용하지 않는다.
ex) 서블렛 넘기지 않기 , HttpSesstion 넘기지 않기
why?
응용 서비스만 단독 테스트하기 어렵다.
표현 영역의 구현이 변경되면 응용 서비스의 구현도 함께 변경 해야 한다.
응용 서비스가 표현 영역의 역할까지 해야한다.
HttpSession은 표현영역의 상태. 응용 서비스에서 변경하면 표현 영역의 코드만으로 표현 영역의 상태 변경과 추적이 어려움
💭 값 검증과 권한 검사
값 검증
값 검증을 표현 영역과 응용 서비스 어디서 하는 것이 좋을까?
용용 서비스에서 할 때
사용자에게 좋지 않은 경험을 제공
사용자는 폼에 값을 입력하고 전송했는데 잘못 입력 했을 때
모든 항목에 대해 잘못된 값이 존재하는지 알고 싶을 것이지만
잘못된 것 하나씩 알려주기 때문에 여러번 다시 입력하게 될 수도 있다.
한 번에 알려주는 방법도 있음
코드가 많아짐
표현 영역에서 할 때
스프링 프레임워크의 Validator 인터페이스를 사용해서 코드를 간결하게 할 수 있다.
나누어 한다면? 필수 값, 값의 형식, 논리적 오류
표현영역에서 필수 값과 값의 형식, 범위 검사 , 응용 서비스에서는 논리적 오류만 검사
필자는 마지막 방법을 선호 했지만 응용서비스에서 모두 하는 것을 선호
작성할 코드가 늘어나지만 응용 서비스의 완성도가 높아지는 이점이 있다.
권한 검사
표현 영역 : 인증된 사용인지 아닌지 검사
서블릿 필터
응용 서비스
스프링 시큐리티 aop로 애너테이션 만들어서 검사
게시글 삭제는 본인이나 관리자만 할 수 있을 때
애그리거트 로딩 후 직접 권한 검사 로직 구현
도메인
조혜온
2024. 02. 22.
클린 코드에 되게 많이 나오는 내용
리스트 보기
'책 > 도메인 주도 개발 시작하기' 카테고리의 다른 글
| Chapter 10. 이벤트 (0) | 2025.03.17 |
|---|---|
| Chapter 8. 애그리거트와 트랜잭션 (0) | 2025.03.17 |
| [도메인 주도 개발 시작하기] Chapter 1. 도메인 모델 시작하기 (0) | 2025.03.17 |
| [도메인 주도 개발 시작하기] Chapter 4. 리포지터리와 모델 구현 (0) | 2025.03.17 |
| [도메인 주도 개발하기] 2장 아키텍처 개요 (0) | 2024.01.30 |