담당역할 : 결제파트

• 역할을 분담해서 작업을 진행했지만 아무래도 겹치는 부분이 생기다보니 같은 기능을 중복구현하는 경우가 발생
  • ex) 결제파트 구현하며 쿠폰사용완료 로직을 처리 했었으나, 기존에 쿠폰생성을 하셨던 경원님께서 완료 API까지 구현해주셔서 결론적으로는 중복기능이 생겼음
  • ⇒ 그로인해 API를 1개로 통일했으면 좋겠다는 프론트의 요청 , 기존에 쿠폰관련 작업을 진행하신 경원님의 API에 있는 method를 결제service에서 호출하여 사용하는것으로 처리

ERD 변경 전

전체회의 이후 미정인 상황이 많이 생겨 기존의 구조가 추후 기획변경 및 확장성 고려시 문제가 많을 수 있고 , 유저테이블에 balance를 넣어두는것보다 별도로 빼내는것이 관리에 용이하다고 느껴져서 구조변경이 필요하다고 느낌

• 현재 판매자 대금에 관련한 정책 별도로 존재하지 않음.
• 결제 상세내역 프론트에서는 구현되지 않을예정

ERD 변경 후

결제테이블 구조 변경이유 및 상세예시

기존

데이터 중복성 및 일관성 관리의 어려움 발생

기존 설계된 구조는 자칫하면 사용자 정보가 중복될 수 있는 문제점이 있습니다.

ex ) 어떤 사용자가 여러 제품을 주문하고 결제하는 상황

Users
	id, name, email, balance

Payments
	id , user_id, amount, status

Orders
	id, user_id, product, payment_id

사용자 정보 중복될 가능성 있음.

정보 변경시 모든 연관된 결제 및 주문 레코드에서 업데이트 해줘야하는데 , 이로 인해 데이터 일관성 유지가 복잡해질 수 있음.

변경 (paymoney 분리한 경우)

Users
	id, name, email

PayMoneys
	id , user_id, balance

Payments
	id , user_id, amount, status

Orders
	id, user_id, product, payment_id

사용자정보와 잔액정보를 분리하여 사용자정보 변경시 사용자 테이블에서만 업데이트

잔액 정보는 결제이력과 분리하여 관리하므로 데이터 일관성을 보다 쉽게 유지가 가능

기존 : 사용자 정보, 결제정보 동일한 테이블에 함께 저장 그로 인해 사용자정보변경시 사용자정보 뿐만 아니라 결제정보와 관련된 테이블에도 전부 다 업데이트 해줘야함.

변경 : 사용자정보, 결제정보 별도 테이블에 저장

사용자 정보 변경시 사용자정보만 업데이트 하면 된다.

⇒ 분리한 경우가 데이터 일관성 및 무결성을 유지하기에 더 간단하며 , 결제 트랜잭션을 관리할 때 좀 더 안전한 방법으로 보였습니다.

또한, 지난번 짧은시간(2일) 결제파트를 맡은적이 있으나

이번에는 처음부터 맡게 되어 시간적인 여유도 있고,

두번째 같은 역할을 맡았음에도 불구하고 처음결과와 크게 달라진것이 없으면

제가 이 파트를 맡은 의미가 없다고 생각이 들어 맡은 파트에 관하여 좀 더 상세하게 다뤄보고자 변경하였습니다.

이와 같이 기록 하였으나 작업 마무리 약 5일 전 , 제가 구현한 결제와 다른분께서 구현하신 주문의 파트가 연관관계에서의 문제가 있다는것을 발견 (이것은 확실한 소통의 문제! )