8월 11일 개발 로그
- 영속성Entity(JPA)랑 도메인 Entity(도메인 그자체)를 분리하는 것에 대해 어케 생각하신아ㅛ
- 도메인 자체가 복잡하고, 테이블자체는 괜찮을 것 같다는 생각이 들었습니다
- 걱정되는건 그건데 도메인 -> 엔티티, 엔티티 -> 도메인시 데이터 정합성 잘 맞춰갈 수 있냐 도메인 -> 엔티티에서 특히 걱정됨 근데 해보질 않아서 걱정되는거긴해서 재밌을것같오
결론 일단은 하나로가고 이후에 리팩터링 진행할 때 나눠보자! (당장은 도메인을 이해한
10개를 삿는데 3개만 환불한다??
결론 금지!
| Tag Name | Description |
|---|---|
| Feat | 새로운 기능을 추가 |
| Fix | 버그 수정 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
| Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서 수정 |
| Test | 테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음 |
| Chore | 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
구매 하면 void말고 거래 당시 금액, 수량 정도 반환해줄 수 있어?? .. 가격을 알 방법이 없어서 ㅎㅎ
호석, 민석
그러면 auctionService.getAuction을 통해서 우리가 경매상품 정보를 가져오고, 그 정보로 요청하는 건가?! 그것도 생각했는데 그 사이에 getAuction한 가격이랑 실제 요청할때의 가격이 달라질 수 있지 않을까 해서 사용자가 3000원으로 보고 구매 요청을함 근데 요청하려고 보니 그 사이에 2000원이 되어서 구매(id, 5개, 3000원)요청을 승인해 주어야 하나?
이 부분도 조금 고민되는것 같아🙃 근데 저 문제는 내가 제안한 방식도 문제가 될것같네..?
동근, 현식
[생각1] - AuctionService 입장 가격이 3000원에서 -> 2000원으로 할인되었을 경우 아래와 같이 동작하는걸 생각해봤는데 3000원 요청에 대해서는 가격이 맞지 않으니 예외 반환 2000원에 대해서 재요청하기
[생각2] - 어느 패키지인진 모르겠음 결제만 담당하는 PaymentService랑 입찰가능한지 확인하는 AuctionService 사이에 이 둘을 이어주는 새로운 서비스가 잇어야하려나~?
- 향후에 트랜잭션을 사용하지 못할 수도 있음 (MySQL을 사용하지 않을 수도 있음)
- 기술에 의존적인 코드가 됨
