인프런 커뮤니티 질문&답변
작성한 질문수
Order->Payment->Cancel 형태에서 경계의 모호함이란?
해결된 질문
작성
·
74
·
수정됨
1
안녕하세요, 강사님.
취소-요구사항 느끼기 수업(4:45~)
Cancel을 '결제의 취소'로 취급하여
Order -> Payment -> Cancel 형태로 개념들이 관계된다면 중심이 Payment로 쏠리고, 기능 확장 시 Order와 Payment, Cancel의 경계가 명확하지 않다고 말씀하셨는데
기능 확장이 어떤 식으로 일어날 때, 왜 경계가 명확하지 않은지 설명해주셨으면 합니다.
이 부분에 대해서는 전혀 그림을 그리지 못하고, 이해하지 못해 제가 어떤 생각을 하는지를 말씀드릴 수가 없네요.
감사합니다.
퀴즈
취소 초점을 결제에서 주문으로 전환하는 것이 시스템 커뮤니케이션에 유리한 이유는 무엇일까요?
결제 게이트웨이 통합을 단순화함
주문 처리를 부차적으로 만듦
내부 및 외부 커뮤니케이션을 개선함
금융 정산을 우선시함
답변 2
1
안녕하세요 질문 감사드립니다!
Order -> Payment <- Cancel 형태로 Payment 가 중심을 가져가도록 구성한다면
추후 배송이 생길 경우 자연스레 Order의 상태가 중심이 되지 않고 Payment의 "결제완료" 상태가 중심이 될 수 있습니다, 물론 이것이 틀린 것은 아니나 강의에서 말했든 "결제는 주문을 완료 시키기 위한 행위"로 서비스의 기준을 정하려고 하기 때문에 명확하게 경계를 긋는게 좋다고 봅니다!
또한 추가적으로 주문에 대하여 다른 기능으로 확장 될 시 Payment 가 중심이라면 상태에 대한 책임과 조회 시 Payment 를 계속 체크해야하는 등의 형태로 Order 와 Payment가 짝꿍처럼 다녀야하는 문제가 있을 수 있어보입니다!
모쪼록 답이 되었길 바랍니다! 감사합니다!
그렇게 이해하셔도 될 것 같습니다!
중요한건 장기적으로 기능이 확장되어갈 때를 대비하기 위해서 어디를 중심으로 할 것이냐 에 대한 결정이 필요합니다
대부분 일정이나 개인플레이 등 여러 사정 때문에 이 부분을 명확하게 하지 않고 넘어가면서 부터 문제의 씨앗이 심어진다고 봅니다
기준이 없으니 어느 쪽을 맞춰야할지 모르겠고, 기능 여러개를 개발하다보면 누구는 이렇게하고, 누구는 저렇게하고 신규입사자는 어쩌란건지 잘 모르는 상황이 생겨버리죠
그래서 명확하게 전략을 정하고 경계를 지어놔야한다고 봅니다!
이 강의에서는 의도적으로 Order를 중심으로 개념 및 코드를 구성 했다고 봐주시면 될 것 같습니다!
0
안녕하세요, 인프런 AI 인턴입니다. 백엔드해야지님.
여러 복잡한 비즈니스 로직과 개념이 얽혀 있는 경우, 개념 간의 경계가 불명확해질 수 있습니다. Order, Payment, Cancel 등의 개념은 각각의 역할과 책임을 명확히 하여 모듈화하는 것이 중요합니다.
경계의 모호함에 대한 이해:
기능 확장 시 경계가 모호해질 수 있는 이유:
- 다양한 기능이 추가될 때 각 개념의 역할이 불분명하면, 특정 기능이 어디에 속해야 하는지 결정하기가 어려워집니다. 예를 들어, ‘결제 취소’ 기능이
Payment나Cancel중 어디에 속해야 할지 모호할 수 있습니다.
- 다양한 기능이 추가될 때 각 개념의 역할이 불분명하면, 특정 기능이 어디에 속해야 하는지 결정하기가 어려워집니다. 예를 들어, ‘결제 취소’ 기능이
기능 확장이 경계 모호성에 영향을 미치는 방식:
- 새로운 비즈니스 요구사항이 추가될 경우, 예를 들어, 새로운 결제 방식이 추가되거나, 취소 정책에 변화가 발생할 때, 각 개념이 자기 역할을 중심으로 확장되지 않는다면, 모든 변화가
Payment에 집중될 위험이 있습니다. 이는 코드 복잡성을 증가시키고 유지관리를 어렵게 만듭니다.
- 새로운 비즈니스 요구사항이 추가될 경우, 예를 들어, 새로운 결제 방식이 추가되거나, 취소 정책에 변화가 발생할 때, 각 개념이 자기 역할을 중심으로 확장되지 않는다면, 모든 변화가
해결 방안:
- 각 개념의 책임을 명확히 정의하고 변경에 유연한 구조 설계를 해야 합니다. 예를 들어,
Order는 주문 정보 관리,Payment는 결제 상태 관리,Cancel은 주문 취소와 관련된 로직을 처리하는 방식으로 책임을 분할할 수 있습니다.
- 각 개념의 책임을 명확히 정의하고 변경에 유연한 구조 설계를 해야 합니다. 예를 들어,
아래 관련 질문 링크를 통해 더 깊이 있는 논의를 참고하실 수 있습니다:
- Cancel - 기능 확장을 바라보는 관점에서 질문 - 취소 매커니즘의 경계와 확장성에 대한 논의가 있음.
- 도메인 계층에서 의존 관계 관리 - 도메인 간 의존성과 확장성을 고려한 모듈화 사례.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
개념적으로는 '주문'을 중심으로 개념 간 관계를 전개하기로 했으나, 코드 상에서 표현되는 관계가 Order -> Payment <- Cancel 형태로 '결제'가 중심이 되면 개념적인 관계 정의와 코드 상의 관계가 일치하지 않아 기능 확장 시 어떤 관계를 따라야할지 모호해지는 상황을 경계가 명확하지 않다고 표현하실걸까요?