core-enum 모듈에 대하여
안녕하세요 제미니님
코드를 보다가 core-enum 모듈에 대해 궁금점이 생겨 질문드립니다.
core-enum의 경우 core-api와 db-core에서 의존성을 받아 쓰고 있는데요.
core-api가 db-core를 의존성 받아 사용하고 있고 core-enum에 있는 값들은 모두 db-core에서 사용하고 있습니다. 이런 경우 그냥 db-core에 enum 값들이 있어도 될거 같은데 굳이 따로 모듈로 빼신 이유가 궁금합니다 !
최대한 생각해본 바로는 db-core를 사용하지 않는 또 다른 모듈에서 사용한다는 가정 밖에 떠오르지 않습니다.
혹시 다른 이유가 있을까요?
답변 1
1
지헌님 질문 감사드립니다!
기본적으론 적어주신대로 enum 의 경우 다른 추가 모듈에서도 사용할 가능성이 많기 때문에 분리해둔 상태입니다
그 외 느낌적 관점이 하나 더 있는데요, 현재 우리가 상황상 이 구조를 선택했지만 최소한의 미래의 다음 스텝의 구조에 대해서도 준비를 해둬야한다고 생각합니다, 그래야 좀 더 수월히 진화를 할 수 있으니까요!
그 관점에서 db-core 에 모든 enum 이 들어가있다면 enum 의 주인 자체가 db에 의존 된 형태로 보이게 되고 추후 구조를 변경하려할때 db-core 에 대한 강한 의존이 걸림돌이 되게 됩니다
(물론 그때가서 다시 찢는 작업이 불가한건 아니지만, db-core 에 enum 들이 있다면 다른 팀원의 작업 시 쉽게 db 의존적인 코드를 enum 안에 넣을 수 있어서 더 큰 오염도가 존재할 수 있습니다)
이런 추가적인 관점도 있어서 enum 모듈은 분리되어있다고 보시면 됩니다!
답이 되었으면 좋겠네요! 추가 질문도 편하게 주시고 완강 후 수강평도 기대합니다!
궁금한점이 여러개 생겼습니다.
1
38
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
55
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
77
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
85
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
76
2
새로 개발한다면 구현 순서
1
136
1
의존 방향에 대한 고민
1
125
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
98
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
84
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
98
1
PG 결제 승인 로직
1
130
2
QnA에서 Join 필드 표현법
1
90
1
결제서비스 콜백 동시성문제 가능성
1
110
2
굿
1
109
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
137
2
도메인 객체와 엔티티 객체 사용
1
139
2
CouponService 의존성 의문
1
98
2
상품 목록 조회 고도화 질문
1
112
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
제품상세 코드 느끼기
1
144
2