[TIL] 221124 - SpringBoot Part2 과제를 진행하며 (객체지향적인 DB 설계)

SpringBoot Part2 과제를 진행하며 :객체지향적인 DB 설계하기

 

※ 주관적인 글입니다!

 

 

심화과제를 진행하며, 단지 과제 요구사항을 충족시키며 개발공수를 낮추려는 방식 같다는 리뷰를 받았다.

심화 과제 요구사항

 

피드백을 받은 기존 테이블 구조

• 바우처와 고객 테이블의 관계가 1 : N 이기때문에 굳이 중간 매핑테이블을 만들 필요가 없다고 생각했다. 멘토님 말씀대로 요구사항을 모두 충족할수 있는대 굳이 복잡한 구조를 만들 필요없다고 생각했다.

 

 

해당 구현 방식이 우리가 그토록 말하던 결합도와 응집도를 높이는 코드인가 다시 고민해볼 필요가 있을 것같다. 또한 오버엔지니어링과 확장성을 가져가는 것의 차이를 생각해봐야한다.

확장성에 가이드라인이 있을 경우 확장성을 선택하는 것이 맞고 확장성이 전혀 없는 구조라면 오버엔지니어링이라고 생각하는게 맞다고 하셨다.

 

기존 방식으로 구현을 할 경우, 바우처와 도메인이 너무 강한 응집도를 가져 따로 생각할수 없는 개념이되어버린다. 이럴 경우 오버엔지니어링을 고민할 필요없이 확장성을 가져가야한다.

Voucher와 Customer의 관계가 사라졌을 경우를 생각해보자, Wallet 테이블이 따로 있다면 해당 관계에 관한 레코드만 삭제하면된다. Voucher와 Customer 객체를 직접적으로 변경할 일이 없다. 하지만 내가 구현한 방식에서는 관계가 사라졌을때 Voucher 레코드가 update되어야한다. 강한 결합이 되어있다는 것을 알 수 있다!

두 객체가 종속관계에 있는 것이 아닌 별개의 객체이기때문에 이러한 강합 결합은 적합하지않다. (아무리 1 : N의 관계여도)

 

 

 

수정한 테이블 구조

 

VoucherWallet이라는 mapping 테이블 추가하였다.

 

 

물리적이지 않은 개념을 논리적으로 구현하는 것은 쉽지않다.

 

내 리펙토링이 정답인지는 여전히 잘 모르겠다. 하지만 기존 구조보다 훨씬 깔끔하게 관리가 가능하다는 것을 느낄 수 있었다.

 

리뷰를 받으며 jpa나 모놀리스에 대한 이야기가 잠깐잠깐 나왔는데 다 이해하진 못하였다. 차차 배우다보면 전부 알게 될거라 생각한다. 🙂

무엇인가를 새로 알아간다는 것이 아직까진 즐거운것 같다! 

 

 

 

함께보면 좋을만한 포스팅

https://codingdog.tistory.com/entry/다대다-관계에서-많이-쓰는-mapping-table을-간단하게-알아봅시다

https://pangtrue.tistory.com/342#:~:text=객체