신뢰성을 고려한 결제 시스템 설계
결제 시스템의 기본 원리와 구성요소
트랜잭션 처리와 동시성 제어
결제 프로세스의 이해
학습 대상은
누구일까요?
결제 시스템이 궁금한 백엔드 개발자
실전 프로젝트를 하고 싶은 학생
선수 지식,
필요할까요?
Kotlin
Spring Webflux
Spring Data Jpa
Spring Data R2DBC
MySQL
Apache Kafka
976
명
수강생
52
개
수강평
38
개
답변
4.5
점
강의 평점
3
개
강의
안녕하세요.
저는 개발자면서 교육자로 신뢰할 수 있는 강의를 만들려고 노력하고 있습니다.
강의를 만들 땐 필요한 지식과 기술을 군더더기 없이 전달하는 정보 밀도 높은 콘텐츠를 제공하려고 합니다.
제가 관심있는 분야, 정말 의미 있다고 믿는 영역에만 강의를 만들며, 누구나 만들 수 있는 강의는 만들지 않습니다.
추가로 커리어리에서도 유용한 글들을 쓰고 있습니다.
- (前) 카카오엔터프라이즈 소프트웨어 엔지니어
- (前) 카카오 Ground X 소프트웨어 엔지니어
전체
21개 ∙ (7시간 8분)
해당 강의에서 제공:
전체
22개
4.4
22개의 수강평
수강평 1
∙
평균 평점 4.0
4
This lecture is perfect in terms of topic, content, and code... It's such a shame that it's hexagonal architecture. If it weren't for this, I'd give it 5 stars... I'm not even sure if hexagonal is a necessary architecture. ㅠㅠ Rather, the payment logic was harder to understand... I couldn't concentrate well because it was a lecture about payment. If it weren't for this, it would be perfect. The lecture materials are organized really neatly, so they're easy to understand, and I like that they put a lot of thought into editing. Hexagonal... If only this were excluded, it would be 100,000 points... I'm looking forward to the next lecture!
수강평 24
∙
평균 평점 4.6
5
I'm embarrassed to say this, but I'm a career employee. I was in charge of a delivery app brokerage service at my previous company, and I had domain knowledge of order and payment services, so I thought I would be able to take this course easily. But no.. It's very difficult.. It's not beginner level.. The order system at my previous company was ridiculous.. It definitely feels like I'm learning a higher version of a payment service in terms of technology.. As in the review below (Ahyo), knowledge of Kotlin, reactive, hexagonal architecture, and Kafka is required as a basic base, and if you know Java, SpringBoot MVC, you might be very busy following the code. However, I think that this course is something that you should keep watching until you properly understand it in order to build your capabilities in payment services. I think it's very important.. (I'm a noob so it's very difficult for meㅠㅠ) After completing this lecture, if I have time, I should study it properly again while refactoring it to the Java and Spring MVC patterns that I originally knew, and definitely acquire the knowledge.. I feel mentally exhausted after meeting that challenger in LoL I feel motivated to study harder
Thank you for the great review! It's a familiar nickname. I think I should have briefly explained the nuclear accident architecture, Kotlin, and reactive to make it easier to follow the lecture. I thought a lot about whether to include this explanation, but I didn't include it because I thought it would be too much of a hassle. However, I didn't use difficult Kotlin grammar or anything, so I think it won't be too difficult! I'll try harder to explain it more kindly and easily in the next lecture. Thank you for the good feedback~~
수강평 7
∙
평균 평점 5.0
5
It was great to be able to gain good knowledge through a solid payment service! Personally, data consistency is a very important part of payment service, so it was great to be able to acquire various technologies so that it is not missed. It would have been better if it had been done in Java, and the focus was on a 'solid payment service', but there were some difficult parts about introducing spring webflux. I think it would have been difficult for students who do not know spring webflux to approach it.
수강평 16
∙
평균 평점 4.2
3
Although it is said that it is not a simple reuse rearrangement, it is a bit disappointing that it does not properly explain the double-entry ledger or the basic ledger/wallet concept. In many ways, it seems like a topic that is a bit off topic for payment systems.
Should I have introduced a more detailed history, such as why the Ledger System came out? I think I have explained the core parts of the Double Ledger and Wallet systems sufficiently. I don't think you have heard the Ledger and Wallet part, but I don't understand what you said about simple rearrangement/reuse. I would like to ask if there are many concerns about actually implementing the theory.
I am not saying that how it is implemented is important. What I want to say is that if you simply look at the fields, debit or credit, and the table name uses the concept of ledger as a ledger, and the concept of double entry, which is the name of double-entry bookkeeping, then this part needs to be explained. Don't you need to understand double-entry bookkeeping to some extent and explain how to implement this double-entry bookkeeping to reliably track and manage payments? Isn't this understanding the domain and understanding the definition and requirements of the domain? Isn't this the right way to properly explain this payment domain? In this lecture, you present a code that operates the general payment process reliably and show how to manage it as an event with Kafka and the process of managing transactions in this process. In my opinion, the payment domain is not the main focus, but Kafka and transaction management are the main focus, and these are simply shown in the payment process. It's not that the instructor was not prepared enough or the lecture content was not sincere. I paid 100,000 won hoping that it would solve my curiosity about the payment domain, but I feel like I didn't get much out of it, so I left a sharp review. I left 2 points in anger, but I changed it to 3 points and am leaving.
수강평 2
∙
평균 평점 5.0
₩148,500
지식공유자님의 다른 강의를 만나보세요!
같은 분야의 다른 강의를 만나보세요!
![Database Oracle + PL/SQL [2025 Revised Edition]강의 썸네일](https://cdn.inflearn.com/public/course-324996-cover/82b6156a-e90c-409c-a3ca-e4e98e810ae1?f=avif&w=420)
