[멋쟁이사자처럼 백엔드 TIL/ 그때 살껄;;..] 거래 시퀀스 다이어그램

1. 서론

내 코드의 동작 방식을 가장 직관적으로 설명할 수 있는 방법으로 시퀀스 다이어그램을 선택했다. 원래같은 경우에는 Object도 전부 클레스로 찢고 메서드와 파라미터까지 다 표시해줘야하시만 시간상 그건 안될 것 같고 부분적으로 보여줘도 충분하겠다 싶어서 간단하게 작성했다. 그럼 시작하겠다.

2. 구매 주문

request를 받아올때 이미 시큐리티에서 사용자 인증을 받기도 하지만 한번더 검사하는 방식을 선택했다. 거래에서 에러가 나면 위험하다 생각했다.

1. 컨트롤러에서 주문을 받는다
2. 주문을 ranscationService에 넘겨서 맞는 구현 클래스로 넘긴다
3. Impl에서 로직을 처리한다.

여기서 중요하게 봤던 점은 @Transcation이다. Jpa는 트렌젝션이 먹어서 괜찮지만 카산드라는 트렌젝션이 통하지 않는다. 따라서 최대한 카산드라에 데이터를 저장하거나 카산드라에 데이터를 삭제하는 로직이 있다면 가장 뒤로 빼고 카산드라 예외처리를 지정해줘서 다른 jpa로직이 트렌젝션을 먹도록 진행한다.

2. 판매 주문

구매 주문과 다른점이 딱히 없다 구매 주문에서는 돈이있는 계좌를 사용했다면 판매 주문에서는 코인 계좌에서 코인을 확인하고 등록하는 방식이 다르다.

3. 일괄 체결

1. 코인 가격이 변하는 이벤트가 발생한다.
2. 코인가격에 의해서 체결이 되야만하는 주문들을 카산드라에서 가져온다.
3. loop를 통해서 체결들을 List에 저장한다.
   transaction Repostitory에서 카산드라에서 불러온 id값을 통해서 각각 받아와야 한다.
4. batch를 통해서 한꺼번에 리파지토리에 저장한다.
5. 카산드라에 매칭된 주문을 전부 삭제한다. 이때 바로 삭제가 되지 않고 카산드라의 Tombstone를 사용해서 데이터를 안전하게 삭제한다.

4. 결론

로직이 변할수도 있다고 생각한다. 하지만 설계를 통해 로직을 만듬으로써 내가 뭘해야하는지 어떤 코드를 작성해야하는지 이해할 수 있었다. 이를 통해서 다른 사람들도 복잡한 코드를 볼 필요 없이 편하게 설계 과정 및 로직으 확인할 수 있게 됐고 나중에 내가 아닌 다른사람이 이 코드를 변경해야한다고 해도 유지 보수가 쉬워지지 않을까 하는 소망이 있다. 개발자라고 해서 코딩만하는게 아니라 이런 문서화도 신경써야한다는 것을 협업을 진행하면서 항상 느낀다.

 

지금 transaction Repository에서 값을 각각 가져와야해 DB부하가 걸린다는 위험성이 있다. 이를 추후에 해결해야한다.