-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
안녕하세요 아랫분 질문에 서 궁금한점이 있어서 질문드립니다
23.10.26 00:13 작성 조회수 258
0
교정하면 Service Class에서 Repository를 이용해서 Member를 가져옵니다. Repository는 MemberEntity를 Member로 변환한 도메인 모델을 반환해야 합니다. 서비스는 MemberEntity를 알지 못해야 합니다.
이렇게 말씀해주셨는데
1 .이렇게 분리하는 이유는 서로의 결합을 낮추기 위해서인가요?
이렇게 분리를하면 어쩔수없이 서비스 메서드 안에
도메인클래스로 변환하는 로직이들어가 오히려 코드가 길어져서
가독성을 해치지는않나요?
현재 저는 서비스에서 레파지토리에서 엔티티를 가져온후
dto 객체로 변환시켜서 (바로 변환을 시키거나 어셈블리라는 클래스를 만들어 여기서 변환 작업을 따로해주는 객체를 만들거나)
컨트롤러로 넘겨줍니다.
보편적으로 이방식을 많이했는대
따로 도메인 클래스를 생성해서 변환해서 비즈니스로직을 처리하고 dto 객체로 넘겨서 컨트롤러로 전달하는지 왜? 이런건지
좀더 자세히 설명해주시면감사하겟습니다
( 제가 수업을 좀더 열심히듣지않아 질문이 무례한게있음 용서해주세요 ㅠ ㅠ)
답변을 작성해보세요.
1
인프런 AI 인턴
2023.10.27
안녕하세요 권기준 님, 인프런 AI 인턴이에요.
서비스 클래스와 리포지토리 클래스를 분리하는 이유는 결합도를 낮추기 위해서입니다. 결합도가 낮으면 각각의 클래스가 독립적으로 변경 가능하고 유연하게 확장할 수 있습니다. 즉, 서비스 클래스가 리포지토리 클래스의 내부 구현에 종속되지 않고, 리포지토리 클래스도 서비스 클래스의 변경을 신경 쓸 필요가 없도록 합니다.
분리된 도메인 클래스로 변환하는 작업은 가독성을 해치지 않습니다. 실제로는 변환 작업이 진행되지만, 이 작업은 도메인 클래스 자체에서 수행되기 때문에 서비스 클래스의 메서드 구현이 길어지는 일은 발생하지 않습니다. 도메인 클래스는 비즈니스 로직을 포함하고, 데이터 변환과 관련된 로직을 가지고 있을 수도 있습니다.
보편적으로는 도메인 클래스를 생성하고 변환하여 비즈니스 로직을 처리하는 방식을 많이 사용합니다. 이는 도메인 클래스 내에 비즈니스 규칙과 연관된 로직을 집중시키고, 외부와의 인터페이스에는 DTO 객체를 사용하여 필요한 데이터만 전달하는 것이 좋은 설계 원칙이기 때문입니다. 또한, DTO 객체를 사용하면 클라이언트와의 데이터 통신에 중복된 필드를 제어할 수 있습니다.
위의 설명이 도움이 되셨길 바랍니다. 질문이 무례하지 않습니다. 언제든지 궁금한 점이 있으시면 편하게 질문해 주세요. 감사합니다!
권기준
질문자2023.10.27
친절한 답변 감사합니다
그러면 예시를 든 코드나 참고할만한 코드가있을까요
그러면 명확하게 도메인클래스는 주로 어떤네이밍? 어떤 식으로 작성되나요
현재 말씀하신 내용들은 모두 UserService or OrderService 등에서 제가 주로하는 작업입니다
(@service 어노테이션을가진)
그런대 이런 서비스들을 도메인 클래스라고 하진않을꺼같고
userDomain 클래스라는 이름을 가진 도메인 객체를 만들고 거기서 @entity객체를받아
도메인 클래스로 변환하고(여기서 예시로 도메인클래스는 어떤이름이될까요)
그리고 그 도메인클래스로 비즈니스로직을 처리한뒤 respons등 Dto로 반환되서 컨트롤러로 넘겨준다는 말씀인가요?
제 질문이 난해햇다면 죄송합니다
0
김우근
지식공유자2024.01.27
안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.
AI가 답변을 잘 달아줬네요. AI 답변에 보충 설명이 있으면 좋을 것 같아 답을 답니다.
이렇게 분리하는 이유는 서로의 결합을 낮추기 위해서인가요?
네 맞습니다. 결합을 낮추기 위함입니다.
서비스에 도메인 클래스 변환 로직
서비스에 도메인 클래스로 변환하는 로직이 들어가면 안 됩니다. 왜냐하면 이렇게 될 경우 결국 서비스가 JpaEntity를 알게 되기 때문입니다. 도메인 클래스로 변환하는 로직은 영속성 객체 쪽에 들어가는 것이 조금 더 자연스럽습니다. 이는 다음과 같이 코드를 만들 수 있다는 말입니다.
@Data
@Entity("member")
public class MemberEntity {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;
private String name;
// MemberEntity를 Member 모델로 변환하는 메서드
public Member toModel() {
return new Member(id, name);
}
// Member 모델을 MemberEntity로 변환하는 정적 메서드
public static MemberEntity from(Member member) {
MemberEntity memberEntity = new MemberEntity();
memberEntity.id = member.getId();
memberEntity.name = member.getName();
return memberEntity;
}
}이런 식으로 도메인 변환 로직을 영속성 객체가 들고 있게 할 수 있습니다. Repository에서 from, toModel 메서드를 사용하도록 하고요. 이러면 서비스 코드의 가독성을 헤치지 않을 수 있습니다.
2번 질문에 후속으로 달아준 의견은 제가 이해를 잘못해서 답변을 드리기 어렵네요…😭
어떻게 하라는 것인지 그래도 헷갈린다면 이쪽 샘플 코드를 확인해 주면 좋을 것 같습니다. (https://github.com/kok202/test-code-with-architecture/tree/v2.0) 후속 강의에서 사용하는 예제 코드인데, 본 강의에서 추구하는 프로젝트의 구조는 위 레포지토리의 v2.0 태그 코드입니다.
답변이 도움 됐길 바랍니다.
답변 2