강의

멘토링

커뮤니티

Inflearn Community Q&A

wulovesk20393's profile image
wulovesk20393

asked

Gemini's Practical Development - Commerce Backend Legacy and AI Application

Payment - Feeling the Code

결제 개념 컴포넌트 분리 기준과 네이밍 전략에 대한 질문있습니다 !

Written on

·

34

1

안녕하세요 ! 결제 개념 쪽 강의 내용 중 궁금한 부분이 있어 질문 드립니다 !

 

1. PaymentCreator를 별도 컴포넌트로 분리한 이유

결제 개념에서 PaymentCreator를 별도의 컴포넌트로 추출하신 이유가 궁금합니다.

결제 생성 또한 결제 개념을 처리하는 기능의 일부라고 생각해서, PaymentProcessor 내부에서 함께 처리할 수도 있지 않을까 생각했는데 Creator를 분리하신 설계 의도가 무엇인지 알고 궁금합니다!

2. Manager vs Processor 네이밍 전략 기준

다른 개념 영역에서는 Manager라는 네이밍을 사용하시다가

결제 영역에서는 Processor라는 네이밍을 채택하신 이유가 궁금합니다.

두 네이밍 사이에 역할적/의미적 차이를 두고 설계하신 것인지, 혹은 도메인 특성에 따른 네이밍 전략인지 궁금합니다 !

spring-boot도메인dbms/rdbmsbackendai-활용-(ax)지금-베스트

Answer 3

1

geminikims님의 프로필 이미지
geminikims
Instructor

안녕하세요 질문 감사드립니다!

[질문1]

제가 느낀 것은 결제의 생명주기큰 기준에서 분리되어 있다고 생각했습니다

생성 -> 성공/실패 이런 느낌으로 나뉘어져있다고 생각하였고 그 기준에서 생성처리(성공/실패)를 분리하게 되었습니다

물론 생성 자체도 단순 처리라고 볼 수 있지만, 이는 행위적으로 생성과 생성 이후에 어떠한 과정으로 인해 발생하는 결과(성공 또는 실패)를 분리하는 구조를 만들고자 했습니다!

 

그렇지만 이는 제가 의도적으로 생명주기를 잘 보이도록하고 느낌을 보여드리고자 나눈 것이지 실제 적어주신 것 처럼 Processor로 처리하는게 이상하지는 않습니다!
모쪼록 이러한 관점을 참고하셔서 한번 생각해보시면 좋을 것 같습니다!

 

[질문2]

사실 저는 Manager, Processor 라는 이름을 선호하지 않습니다 😅
왜냐하면 클래스 이름을 봤을때 직관성과 명확성이 떨어지기 때문입니다

그치만 실제로 초기 개발시에는 네이밍 때문에 맞추기위해 너무 작은 조각(Reader, Writer, Appender, Updater ....) 으로 쪼개면 그것 대로 비효율과 낭비가 생긴다고 생각하고 그럴때 진화 중간 단계(추후 덩치가 커지면 분리를 위한 단계)로 저런 모호한네이밍을 사용하는 편인 것 같습니다

 

그래서 사실 Manager, Processor, Handler 요런 네이밍 결정시에는 엄청난 기준이 있지는 않습니다ㅎㅎ;
그냥 모여진 함수들의 책임이나 역할의 뉘앙스가 중계하거나 관리 역할에 가깝다면 Manager를 쓰는 것 같고 / 처리 관점의 뉘앙스가 강하면 Processor 라고 지칭하는 편입니다!

 

적으면서 생각해보니 결제 개념에는 처리가 더 자연스럽게 잘 어울리다고 판단한 것 같습니다!


모쪼록 답이 되었길 바랍니다! 감사합니다!

0

wulovesk20393님의 프로필 이미지
wulovesk20393
Questioner

비즈니스를 잘 나타내는 네이밍도 중요하지만 어느정도 일관된 네이밍도 중요하다고 생각이 들어서.. 제미니님께서는 어떤 의도로 네이밍을 지으셨는지 궁금해 질문드렸습니다 !!!

친절한 답변 너무 감사합니다 !! 😃

0

안녕하세요, 인프런 AI 인턴입니다. 정우용님.

님께서 올리신 질문은 백엔드 설계의 핵심인 컴포넌트의 분리와 네이밍 전략에 관한 흥미로운 주제를 담고 있습니다. 강의에서 이러한 부분을 어떻게 다루고 있는지 궁금하신 것 같습니다.

1. PaymentCreator를 별도 컴포넌트로 분리한 이유

  • 책임의 분리: PaymentCreator가 별도의 컴포넌트로 분리된 이유는 각 책임을 명확히 하고, 역할을 구분하여 코드의 가독성과 유지보수성을 높이기 위함일 수 있습니다. 결제라는 복잡한 도메인에서 결제 생성의 기능은 결제 처리 전체와는 조금 다른 비즈니스 로직을 수행할 수 있습니다.
  • SRP(Single Responsibility Principle): 단일 책임 원칙에 따라, 여러 가지 중요한 책임을 한 클래스가 모두 처리하는 것보다, 각 책임을 독립된 클래스로 분리함으로써 변경이 쉽게 가능합니다. 따라서 PaymentCreator를 별도로 두어, 결제 생성 로직과 처리 로직을 명확히 구분하게 됩니다.

2. Manager vs Processor 네이밍 전략 기준

  • 도메인 특성에 맞춘 네이밍: Manager와 Processor의 차이는 주로 해당 컴포넌트가 수행하는 역할의 특성에 기반하여 결정될 수 있습니다. Manager는 보통 관리, 조율의 역할을 의미하고, Processor는 특정한 처리, 실행의 역할을 강조하는 경우가 많습니다.
  • 역할 기반 네이밍: 결제는 다양한 프로세스를 포함하므로, Processor라는 명칭이 더 어울릴 수 있는데, 이는 결제가 여러 단계의 처리를 포함하고 있음을 강조하기 위함일 수 있습니다.

이와 관련한 구체적인 코드 설계와 네이밍 전략에 대한 다양한 논의는 아래의 유사한 질문과 답변을 참고하시면 도움이 될 것입니다:

  1. 테스트 관리 및 의존성 주입에 대한 기존 글: 컴포넌트 분리 및 네이밍에 대한 유익한 토론을 들을 수 있습니다.
  2. 도메인 모델과 엔티티 모델의 혁신적 설계 방법: 실질적인 설계 원칙과 관련된 질문을 통해 깊이 있는 이해를 도울 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

wulovesk20393's profile image
wulovesk20393

asked

Ask a question