[구현] ADD: 디플레이션 시나리오

[yujin-min]

7 디플레이션 시나리오 구현

wallet 개념 추가

• 현재 상황에서는 money와 point가 각각 개별로 다뤄지지 않으니 wallet으로 합쳐서 관리
• 들어온 amount에 대해 money를 생성하고 money를 바탕으로 point 생성
• account의 charge 함수 삭제 후 update로만 관리

  금액 전략 추가(amount-strategy)

• charge(충전): 유저 모듈에서 사용. 새 금액 충전시 비즈니스 계정의 경우 10% 포인트 충전
• adjust(조정): 크론 모듈에서 사용. 잔액을 바탕으로 1% 삭감. 비즈니스 계정의 경우 그 금액만큼 포인트 재충전

  배치잡 추가

• 매일 오전 8시에 모든 유저의 잔액의 1% 삭감

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[yujin-min]

money와 point를 어떻게 하면 더 잘 관리할 수 있을지 궁금합니다 🤔

[f-lab-namu]

money와 point를 어떻게 하면 더 잘 관리할 수 있을지 궁금합니다

요 부분 좀 더 구체적으로 어떤 포인트에서 부분이 우려되거나, 잘 관리 되지 않다고 느끼시는거에요?

[yujin-min]

11 주신 의견 확인했습니다. 🙇‍♀️ @f-lab-namu

account 아래에 충전, 디플레이션이 생기고 각각 usersController, cronService에서 사용하는 것으로 이해를 했습니다. 질문이 있습니다. 다른 컨트롤러에서 산하의 서비스를 거치지 않고 다른 모듈의 서비스를 가져다 쓰는 일이 흔한 일인가요? +) 배운 디자인패턴(?) 적용이 사라졌는데 괜찮을까요

[yujin-min]

money와 point를 어떻게 하면 더 잘 관리할 수 있을지 궁금합니다

요 부분 좀 더 구체적으로 어떤 포인트에서 부분이 우려되거나, 잘 관리 되지 않다고 느끼시는거에요?

뭔가 특정한 이유보다는 제가 객체를 이런식으로 맘대로 조합해도 되는걸까 하고 작성한거라서 혹시 더 좋은 방향이 있나 궁금해서 여쭤봤습니다. 모호한 질문이였네요. 다음에는 좀 더 자세하게 적어보도록 하겠습니다.

[f-lab-namu]

account 아래에 충전, 디플레이션이 생기고 각각 usersController, cronService에서 사용하는 것으로 이해를 했습니다. 질문이 있습니다. 다른 컨트롤러에서 산하의 서비스를 거치지 않고 다른 모듈의 서비스를 가져다 쓰는 일이 흔한 일인가요?

아, 그러고 보니 제가 부연 설명 없이 코드만 드렸네요 ㅎㅎ; 해당 코드의 의도는 다음과 같았습니다: 좀 더 간결하게 코드를 작성하는 예시를 참고삼아 보여드리고 싶었습니다. (Keep It Simple, Stupid 원칙) pattern 이 무언가 필요해서 나오기 보다는 사용하기 위해 작성된 느낌을 받았습니다. (<- 작성하신 코드가 잘못되었다는 피드백이 아닙니다. 코드를 작성하는 현재의 두뇌 알고리즘에서 조금 더 패턴을 생각하는 비중보다 대원칙들을 생각하는 비중을 가져가면 좋겠다는 피드백 입니다. 패턴을 생각하고 코드에서 패턴이 나오는게 아니라, 대원칙을 지키기 위해 자연스럽게 나와야 합니다)

+) 배운 디자인패턴(?) 적용이 사라졌는데 괜찮을까요

패턴 적용 관점에서만 보면 너무 좋았습니다. 정확히 사용하셨다고 저도 생각들었어요 💯 💯

뭔가 특정한 이유보다는 제가 객체를 이런식으로 맘대로 조합해도 되는걸까 하고 작성한거라서 혹시 더 좋은 방향이 있나 궁금해서 여쭤봤습니다. 모호한 질문이였네요. 다음에는 좀 더 자세하게 적어보도록 하겠습니다.

개인적으로 좋지 않은 질문은 없다 라고 생각합니다. 편하게 질문주셔도 되구요. 아마 경험하셨겠지만, 대부분의 개발은 항상 새로운 domain 에 대해 개발하게 됩니다. 심지어 같은 도메인도 시장 상황과, 내부 인력 등의 그 시점에 따라 조금씩 달라져 결국 어떻게 보면 새로운 domain 에 대해 개발하게 됩니다. 실용주의적 프로그래밍 관점에서 볼때 처음부터 완벽히 설계할 수 있는 확률은 매우 낮고 시간도 오래 걸립니다. 그래서 저는 리펙토링에 중점을 두어야 된다고 생각합니다. 설계 보다 리펙토링에 중점을 두는 구체적인 방법으로는 "무엇가 확실하지 않은 것들은 그대로 둡니다". 이번 질문 처럼 객체를 조합해 보셨는데, 해당 결과물에 대해 특별히 나쁜 점이 없다면 그냥 둡니다. 개발을 더 진행해보다가 "확실한" 문제가 발견되면 그때 리펙토링을 합니다.