codeit-spring-6-part2-team2
CountLog 도메인의 구현에 대하여 논의하고자 하는 문제 #30
Replies: 3 comments 11 replies
-
|
@kimdotcom2 님 안녕하세요!
|
Beta Was this translation helpful? Give feedback.
-
|
@mainlib990 1.에 대해서는 저도 같은 생각입니다. PR 해주신 Employee 도메인을 참조해서 별개의 엔티티와 Dto를 만들면 될 것 같습니다. 2.에 대해서는 성능 문제를 신경 쓰지 못해 좀 아쉽긴 하지만, 요구 사항이 그렇다면 어쩔 수 없는 것 같네요. 그러면 추후 동기 처리를 전제로 메소드를 구현하도록 하겠습니다. 3.에 대해서는 어제 저희가 얘기했던 것처럼, 프로토타입의 화면에서는 수정 이전 직원 정보와 수정 이후 직원 정보를 비교해서 보여주고 있습니다. 그것을 구현하기 위해 이야기 드린 것이었는데, 만약 EmployeeService를 참조하지 않는다면 EmployeeService에서는 수정 이전 직원 정보와 수정 이후 직원 정보를 모두 로그로 DB에 남겨야 할 것 같네요. 1.에서 언급하신 엔티티에서 수정 전 로그인지 수정 이후 로그인지 판단하는 칼럼도 추가해야 할 것 같고요. 아마 Dto도 그런 방향으로 설계해야 할 것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
맞아요. Dto자체를 ChangeLogService에 맞는 Entity로 변경하시고 모든 이력을 저장하고 있어야할것같아요. 그래야 도메인 객체에서 해당 정보 기반으로 올바른 Response를 만들어줄수 있을걸로 예상돼요. |
Beta Was this translation helpful? Give feedback.
-
|
3.에 대해서 프로토타입 확인 결과, 해당 로그가 남은 시점에서의 수정 이전 직원 정보와 수정 이후 직원 정보를 보여주고 있네요. 수정 전과 수정 후 양쪽 모두를 파라미터로 받도록 수정 이력 메소드 시그니처를 설계하도록 하겠습니다만, 괜찮으실까요? create 로그 메소드 - 수정 후 직원 정보만 받음 제 쪽에서 직접 Employee 엔티티를 참조해서 Employee 테이블에서 읽어오지 못하니, 메소드를 호출하는 측에서 Dto 형태로 직원 정보를 넣어주어야 합니다. |
Beta Was this translation helpful? Give feedback.
-
|
현재 제가 구상하고 있는 interaction interface의 코드 형태는 이렇습니다. public interface ChangeLogService {
...
//직원 생성 시 로그 생성
ChangeLogDto addCreateEmployeeLog(EmployeeLogDto.CreateLogRequest request);
//직원 정보 수정 시 로그 생성
ChangeLogDto addUpdateEmployeeLog(EmployeeLogDto.CreateUpdateLogRequest request);
//직원 퇴사 시 로그 생성
ChangeLogDto addDeleteEmployeeLog(EmployeeLogDto.CreateDeleteLogRequest request);
}
public class EmployeeLogDto {
private EmployeeLogDto() {
}
@Builder
public record EmployeeBaseInfo(
LocalDateTime hireDate,
String name,
String position,
String department,
String email,
String employeeNumber,
String status
) {}
public record LogMetadata(
@Nullable
String memo,
String ipAddress
) {
public static LogMetadata withMemo(String ipAddress, String memo) {
return new LogMetadata(memo, ipAddress);
}
public static LogMetadata withoutMemo(String ipAddress) {
return new LogMetadata(null, ipAddress);
}
}
@Builder
public record CreateLogRequest(
EmployeeBaseInfo employeeInfo,
LogMetadata metadata
) {}
@Builder
public record CreateUpdateLogRequest(
EmployeeBaseInfo before,
EmployeeBaseInfo after,
LogMetadata metadata
) {}
@Builder
public record CreateDeleteLogRequest(
EmployeeBaseInfo employeeInfo,
LogMetadata metadata
) {}
}새 직원이 들어오거나 직원이 퇴사하였을 때 인자로 주어질 Dto의 형태는 비슷합니다. 직원 정보를 수정할 때 생성하는 로그는 기존의 직원 정보와 수정할 새로운 정보가 모두 필요합니다. |
Beta Was this translation helpful? Give feedback.
-
|
#36 이슈 생성 완료. |
Beta Was this translation helpful? Give feedback.
-
|
음... 로직을 어떻게 짤지에 대한 질문으로 이해되는데 맞을까요?? |
Beta Was this translation helpful? Give feedback.
-
|
@kimdotcom2 갑자기 든 생각인데 |
Beta Was this translation helpful? Give feedback.
-
|
@kimdotcom2 님. 다시 생각해봤는데 어떤 이벤트인지 구분이 필요해보여 API 재디자인이 필요해보입니다. 다음과 같은 방법들이 존재할걸로 예상됩니다:
위와 같은 해결 방법이 있을걸로 예상 되는데 1번의 경우가 좀더 직관직이지만 JDK 17+을 요구할걸로 예상됩니다. 혹시 JDK 버전 투표 필요하시면 Discussion에 올려주세요. |
Beta Was this translation helpful? Give feedback.
-
|
저로써는 2번 방법이 지금 상황에 좋다고 생각하네요. 일단 현재 DTO 구조 자체가 2번 방법에 더 적합한 상황에서, 시간이 촉박한 지금 상황에서는 가장 구현 복잡도가 간단하다고 생각합니다. 저로써는 직관성이 조금 떨어진다는 점을 제외하면 2번 방법에 큰 문제점은 없다고 봅니다. public class EmployeeLogDto {
private EmployeeLogDto() {
}
@Builder
public record EmployeeBaseInfo(
LocalDateTime hireDate,
String name,
String position,
String department,
String email,
String employeeNumber,
String status,
//삭제 여부를 판단하기 위한 필드
boolean isDeleted
) {}
public record LogMetadata(
@Nullable
String memo,
String ipAddress
) {
public static LogMetadata withMemo(String ipAddress, String memo) {
return new LogMetadata(memo, ipAddress);
}
public static LogMetadata withoutMemo(String ipAddress) {
return new LogMetadata(null, ipAddress);
}
}
@Builder
public record CreateLogRequest(
EmployeeBaseInfo employeeInfo,
LogMetadata metadata
) {}
@Builder
public record CreateUpdateLogRequest(
EmployeeBaseInfo before,
EmployeeBaseInfo after,
LogMetadata metadata
) {}
@Builder
public record CreateDeleteLogRequest(
EmployeeBaseInfo employeeInfo,
LogMetadata metadata
) {}
}무엇보다 제가 switch문의 패턴 매칭에 익숙하지 않습니다... 그리고 엔티티 설계에 대한 궁금한 점이 있습니다만, 일단 지금 말씀해주신 사항이 이렇습니다.
|
Beta Was this translation helpful? Give feedback.
-
|
@kimdotcom2 님 좋은 질문 감사합니다.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
1. 도메인 설계 문제
프로토타입에서는 수정 내역의 상세에서 이전 직원 정보와 수정된 직원 정보를 함께 보여줄 것을 요구한다.
그렇다면 변경이 발생했을 때 수정 전 직원 정보도 같이 저장하도록 엔티티를 설계해야 하는 것인가?
어떻게 구현할 것인가?
등등등
2. 수정 이력 메소드 동작 방식 문제
직원 정보 수정 이력은 직원이 추가되거나 직원 정보가 수정되었을 때 같이 생성되어야 한다.
아마도 직원 모듈의 서비스에서 직원 정보 수정 이력 모듈의 서비스를 주입받아 호출하도록 구현할 것이다.
그런데 수정 이력을 저장하는 로직이 완료될 때까지 클라이언트가 기다려야 한다면 지연이 발생해 UX가 저하될 가능성이 있다.
그리고 부가 작업인 로그 저장이 실패했다고 전체 작업을 실패로 간주해 클라이언트에게 에러를 반환하는 것은 합리적이지 못하다.
그렇다면 주입할 직원 정보 수정 이력 모듈의 메소드는 비동기로 작동하도록 구현할 것인가?
3. 순환 참조 문제
2에서 말했듯이 직원 모듈은 직원 정보 수정 이력 모듈의 서비스를 인터페이스를 통해 참조하게 된다.
하지만 1을 구현하려면 직원 정보 수정 이력 모듈은 직원 모듈의 서비스를 참조해 현재 직원 정보를 DTO로 가져와야 할 것이다.
순환 참조 문제를 우려해야 할까?
Beta Was this translation helpful? Give feedback.
All reactions