[#94] 세미나공지사항 게시물 도메인 로직 내에 메일 전송 이벤트 로직 추가 #102
Conversation
kang20
changed the title
| // 게시 상태로 변경이면 뉴스레터 전송 | ||
| if(boardUpdateRequest.isPublished() && board.getTag().equals(Tag.seminar) && board.getStatus().equals(Status.DRAFT)) { | ||
| eventPublisher.publishEvent(EmailNotificationEvent.create( | ||
| BoardType.SEMINAR_SUMMARY, | ||
| SeminarSummaryEmailDeliveryStrategy.create(board) | ||
| )); | ||
| } | ||
|
|
||
| return boardCommandService.updateBoard(boardUpdateRequest, board); |
There was a problem hiding this comment.
P5 : 만약에 boardCommandService.updateBoard에서 예외가 발생한다면 정상적으로 글이 게시되지 않으므로 boardCommandService.updateBoard 실행 전에 뉴스레터 알림 전송을 하는 것은 애매해보이는데 어떻게 생각하시나요?
|
@siwan9 저는 Board라는 도메인 내에 있어서 BoardType이 Board 를 설명하는 타입에 더 적합하다고 생각하는데 어떻게 생각하시나요 |
이거 제생각에는 Board 도메인의 BoardType에서 통합하는 작업이 필요하다 봅니당. 현재 SEMINAR, NOTICE 밖에 없는데 사실 스터디, 프로젝트, 멘토링도 게시물의 일종이니까 한군데서 관리하는게 좋아보이네요. 어떻게 생각하시나요 다들? |
| @Getter | ||
| public class GlobalPageResponse { | ||
| private final int pageSize; // 한 페이지에 게시물 갯수 | ||
| private final int pageNum; // 현재 페이지 number | ||
| private final int totalPage; // 총 페이지 갯수 | ||
| private final String pageSort; // 정렬 ( 내림 or 오름) | ||
| private final List<?> pageContents; // 페이지 제목 관련 | ||
|
|
||
| private GlobalPageResponse(int pageSize, int pageNum, int totalPage, String pageSort, | ||
| List<?> pageContents) { | ||
| this.pageSize = pageSize; | ||
| this.pageNum = pageNum; | ||
| this.totalPage = totalPage; | ||
| this.pageSort = pageSort; | ||
| this.pageContents = pageContents; | ||
| } | ||
|
|
||
|
|
||
| public static GlobalPageResponse from(Page<?> pageDTO) { | ||
| return new GlobalPageResponse( | ||
| pageDTO.getNumber()+1, | ||
| pageDTO.getSize(), | ||
| pageDTO.getTotalPages(), | ||
| pageDTO.getSort().toString(), | ||
| pageDTO.getContent()); | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
P4 : 이거 현재방식으로는 메서드내에서 반환할때
모든 메서드에서 GlobalPageResponse 를 반환하기에 실제 어떤 데이터가 반환되는지 한눈에 확인하기 어려운 것 같습니당.
class 가 제너릭을 사용하는 GlobalPageResponse<T> 방식은 어떨까요?
| - security/application-db.yml | ||
| datasource: | ||
| driver-class-name: com.mysql.cj.jdbc.Driver | ||
| url: ${local-db.rdb.url} | ||
| username: ${local-db.rdb.username} | ||
| password: ${local-db.rdb.password} | ||
| url: jdbc:mysql://localhost:3310/local-mysql | ||
| username: root | ||
| password: 22115533 | ||
| data: | ||
| web: | ||
| pageable: | ||
| one-indexed-parameters: | ||
| true | ||
|
|
||
| redis: | ||
| host: ${local-db.redis.host} | ||
| port: ${local-db.redis.port} | ||
| host: localhost | ||
| port: 6381 | ||
| jpa: |
There was a problem hiding this comment.
깃허브를 clone 받으면 누구든지 어떤 설정 없이 실행 가능한 상태로 만들고 싶어서
라고 하셨는데, 각자 로컬에서 사용하는 db url, username, password 가 다르지 않을까요??
그러면 오히려 환경변수로 두고, .env 작성 방법을 표기하는게 더 좋지 않을까요?
그런데, 저희 운영을 위한 목적의 프로젝트인데 clone을 받아 실행시킬 여지도 남겨놓을 건가요?
만약 clone받아 사용할 수 있다면 저희 security application 파일들은 공유가 불가능한데, 그것들은 어떻게 처리하실 생각이신가요??
There was a problem hiding this comment.
다른 설정은 실행 여부와 상관없다고 판단하긴 했습니다. 무엇보다 로컬 db 설정은 사실 외부로 노출해도 되는데 로컬 db security 커밋 쌓기 좀 번거롭더라고여 그래서 노출하였습니다
There was a problem hiding this comment.
저희 s3나 oauth, mail 등의 설정이 없으면 어플리케이션 실행이 안될 것 같습니당.
그리고 로컬 db 설정은 저희 3명도 다를거라 각자 고쳐서 사용하는 방안으로 생각하긴 했습니당.
사실 변수로하던 지금으로 하던 각자 로컬에 맞게 수정하고 실행해야해서 큰 지장은 없을 것 같긴합니다
There was a problem hiding this comment.
clone 받아 사용할 수 있게할거냐 아닐거냐는 좀 고민해봐야겠네요.
만약 clone을 고려할거라면 서브모듈로 security를 빼는 것 보단 각 application에서 숨길 부분만 변수로 처리하는게 맞아보이긴합니다.
Board 패키지의 BoardType 클래스에서 여러 게시물 타입 관리하는 것 동의합니다. |
음.. 두 게시판의 Type 이름을 변경하는 건 좋은 것 같긴합니다. 근데, 명명을 잘 해야할 것 같아요. @Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class EmailNotificationEvent {
private final BoardType boardType;
private final EmailDeliveryStrategy emailStrategy;
public static EmailNotificationEvent create(BoardType boardType, EmailDeliveryStrategy emailStrategy) {
return new EmailNotificationEvent(boardType, emailStrategy);
}
}
public enum BoardType {
STUDY,
PROJECT,
MENTORING,
SEMINAR_NOTICE,
SEMINAR_SUMMARY;
}현재 newsletter에서는 BoardType이 이렇게 5가지가 필요합니다. 만약 게시글, 공지사항과 스터디, 프로젝트, 멘토링 부분을 따로 가져간다고 하더라도 BoardType 이라는 5가지 타입을 모두 가진 enum이 존재를 해야해요.
현재는 2가지 정도의 해결이 생각나네요 |
|
어느 한 지점에서 전부 관할해야하는 것도 동의합니다. 근데 저는 조금 다른 생각인게 저희 프로젝트에서 정의한 Board 는 공지사항과 세미나 게시판입니다. 지금 현재 다음 타입은 email 대상 컨텐츠들 아닌가요? 그러면 BoardType이라고 명명하는 것보단 EmailTarget 같은 이름이 도메인 성격상 더 적합하지 않나 싶은 의견입니다. 이 의견에는 혹시 어떻게 생각하시나요? public enum BoardType {
STUDY,
PROJECT,
MENTORING,
SEMINAR_NOTICE,
SEMINAR_SUMMARY;
} |
@kang20 혹시 스터디, 프로젝트, 멘토링 게시물은 board라는 이름을 사용하지 않는 것이 적합하다고 보시나요?
지금 만들어진 BoardType은 댓글 쪽에서도 사용하고 있습니다만 추후 리팩토링하여 사용하지 않을 가능성도 있습니다. 스터디, 프로젝트, 멘토링 게시물이 board가 아니라고 생각하신다면 스터디, 프로젝트, 멘토링 도메인에 board 단어를 제외 및 전체 타입을 담는 enum은 PostType으로 명명하고 BoardType은 지금처럼 세미나 관련 타입만 담으면 될 것 같은데 저는 스터디, 프로젝트, 멘토링 게시물도 게시판의 종류 중 하나라고 생각해서 board 단어를 도메인에 붙였습니다. 어떻게 생각하시나요? |
만약 공지사항과 세미나 게시판의 type 또는 스터디, 프로젝트, 멘토링의 type 에서 변경이 일어난다면 EmailTarget(예시) 에 저장된 타입의 이름도 변경해줘야 합니다. 이 부분의 비교는 코드레벨에서 진행되기에 런타임 에러로 이어집니다. 추후 이 프로젝트가 이어졌을 때, 사용자에 실수에 의한 에러가 일어날 가능성이 높아질 것 같습니다. Board 라는 상위 클래스를 만들어 공통 부분을 제외하고, 공지사항, 세미나, 스터디, 프로젝트, 멘토링 도메인에서 상속을 받아 사용하는 방식은 어떤가요? 제가 생각하기에도 위의 도메인들이 모두 게시글 (Board)에 해당하는 것 같습니다. |
🌱 작업 사항
sequenceDiagram actor Admin as "Admin" actor seminar_writer as "ROLE_SEMINAR_WRITER" participant board_system as "세미나/공지사항_게시물_System" participant newsletter_system as "뉴스레터_System" actor subscriber as "뉴스레터 구독자" %% 세미나/공지사항 게시물 상태 변경 섹션 Note right of newsletter_system: 게시물이 게시되면 뉴스레터 시스템에 알림을 보낸다.<br>뉴스레터는 사용자가 구독한 세미나에 대한 정보를 전송하는 기능을 제공한다.<br>**한번 게시된 게시물은 다시 임시저장 상태로 갈 수 없다** Admin ->> board_system: 공지사항 게시물 정보 변경 요청 board_system -->> Admin: 상태 정보 완료 seminar_writer ->> board_system: 세미나 게시물 정보 변경 요청 board_system -->> seminar_writer: 정보 변경 완료 alt 게시 상태가 된다면 board_system ->> newsletter_system: 게시물 게시 알림 newsletter_system ->> subscriber: 신규 세미나 공지사항 알림 end❓ 리뷰 포인트
🦄 관련 이슈
resolves #94