Conversation
| fun from(value: Long): Money { | ||
| return Money(BigDecimal.valueOf(value).setDefaultScale()) | ||
| } |
There was a problem hiding this comment.
Money를 BigDecimal 말고 더 다른 정의가 필요하진 않을까요?
10원 단위이거나, 0원 이상이거나 등등..
There was a problem hiding this comment.
0원 이상 검증 너무 좋네요!
그런데 코드를 추가하면서 생각하지 못했던 일이 생겼어요...
val m1 = Money.from(500)
val m2 = Money.from(1000)
val m3 = Money.from(5000)
m1 - m2 + m3 m1 - m2 + m3을 할 때 결과적으로는 500 - 1000 + 5000 이라서 5500이지만, m1 - m2를 하는 과정에서 음수 Money가 반환되어 예외가 발생하게 되었습니다...ㅠㅠ
Money생성시 0이상을 검증하면, 개발자가 연산 순서를 신경써서 작성해야할 것 같은데 괜찮나요?
아니면 아예 연산 결과를 BigDecimal같이 Money가 아닌 타입으로 반환하게 바꿔야할 것 같네요...ㅠㅠ
There was a problem hiding this comment.
구현 코드를 본 것은 아니지만, init {} 블럭에서 검증하는 게 아니라 from 에서만 검증하면 괜찮지 않을까요?
There was a problem hiding this comment.
위 예시처럼 돈을 계산하는데 있어서 여러 연산 중간에 음수가 나오는 경우가 있나요..?!
There was a problem hiding this comment.
위 예시처럼 돈을 계산하는데 있어서 여러 연산 중간에 음수가 나오는 경우가 있나요..?!
저도 드물거라곤 생각하는데
deliveryFee - couponDiscountPrice + productPrice 이런식으로 짜면 중간에 마이너스 될 수도 있지 않을까요?!!
나중에 스토어 정산까지 추가되면 또 복잡한 로직이 생길 수도 있을 것 같았어요!
There was a problem hiding this comment.
구현 코드를 본 것은 아니지만, init {} 블럭에서 검증하는 게 아니라 from 에서만 검증하면 괜찮지 않을까요?
그것도 방법이 될 수 있겠군요!!
그런데 from으로 생성한 Money만 0이상 검증이 되고, 연산 최종 결과로 반환된 Money는 검증이 안된다면 조금 헷갈릴 수도 있지 않을까요??
There was a problem hiding this comment.
클로드한테 물어보니까 빌더패턴도 추천해주네요 ㅋㅋㅋ..
val totalMoney = m1.toBuilder()
.minus(m2)
.plus(m3)
.build()근데 저는 연산 중간에 마이너스가 나오지않게 개발자가 로직을 알아서 잘 짜는 것도 괜찮은 것 같아요 ㅎㅎ... init {}에 추가해도 될까요?
| private class MoneyDeserializer : JsonDeserializer<Money>() { | ||
| override fun deserialize(p: JsonParser, ctxt: DeserializationContext): Money { | ||
| val value = p.codec.readValue(p, String::class.java) | ||
| return Money.from(value.toBigDecimal()) | ||
| } | ||
| } | ||
|
|
||
| private class MoneySerializer : JsonSerializer<Money>() { | ||
| override fun serialize(money: Money, gen: JsonGenerator, serializers: SerializerProvider) { | ||
| gen.writeNumber(money.value.intValueExact()) // TODO INT? BigDecimal? | ||
| } | ||
| } |
There was a problem hiding this comment.
직접 직렬화 / 역직렬화 하는 것을 선택하셨군요! 멋집니다 👍
혹시 클라이언트의 Request를 BigDecimal 로 받고 이후(toCommand 등) Money 로 변환하는 것과 Request 에서 바로 Money로 받는 것 중 후자를 선택하신 이유는 무엇인가요?
There was a problem hiding this comment.
INT? BigDecimal? 로 적어두신 건 이유가 무엇인가요?
There was a problem hiding this comment.
INT? BigDecimal? 로 적어두신 건 이유가 무엇인가요?
response에서 int로 반환해야할지 bigDecimal로 반환해야할지를 몰라서 개발하면서 적어뒀었습니다...ㅎㅎ 지우는 걸 잊었네요 기존 response와 동일하게 int로 가져가겠습니다!
There was a problem hiding this comment.
혹시 클라이언트의 Request를 BigDecimal 로 받고 이후(toCommand 등) Money 로 변환하는 것과 Request 에서 바로 Money로 받는 것 중 후자를 선택하신 이유는 무엇인가요?
음... 사실 큰 이유는 없고 자주 쓰이는 VO라 매번 Money.from()으로 바꿔주는 것 보다 바로 Money로 받는 게 편하지 않을까~~ 해서 추가했었어요...!
There was a problem hiding this comment.
BigDecimal 로 연산하고 반환은 Int 로 하는 게 살짝 어색한 느낌이 들기는 하는데 다들 어떻게 생각하시나요? 물론 당장 서버에서 문제가 생기지는 않을 것 같습니다!
There was a problem hiding this comment.
음... 사실 큰 이유는 없고 자주 쓰이는 VO라 매번 Money.from()으로 바꿔주는 것 보다 바로 Money로 받는 게 편하지 않을까~~ 해서 추가했었어요...!
덕분에 저희도 편하겠네요~ 👍
There was a problem hiding this comment.
BigDecimal 로 연산하고 반환은 Int 로 하는 게 살짝 어색한 느낌이 들기는 하는데 다들 어떻게 생각하시나요? 물론 당장 서버에서 문제가 생기지는 않을 것 같습니다!
저는 펫쿠아가 원화만 취급하니까 반환은 Int로 해도 괜찮다고 생각했어요!!
📁 작업 설명
Money 값객체 생성