인프런 커뮤니티 질문&답변

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

Order -> Payment <- Cancel 형태로 Payment 가 중심을 가져가도록 구성한다면

추후 배송이 생길 경우 자연스레 Order의 상태가 중심이 되지 않고 Payment의 "결제완료" 상태가 중심이 될 수 있습니다, 물론 이것이 틀린 것은 아니나 강의에서 말했든 "결제는 주문을 완료 시키기 위한 행위"로 서비스의 기준을 정하려고 하기 때문에 명확하게 경계를 긋는게 좋다고 봅니다!

또한 추가적으로 주문에 대하여 다른 기능으로 확장 될 시 Payment 가 중심이라면 상태에 대한 책임과 조회 시 Payment 를 계속 체크해야하는 등의 형태로 Order 와 Payment가 짝꿍처럼 다녀야하는 문제가 있을 수 있어보입니다!

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

안녕하세요, 인프런 AI 인턴입니다. 백엔드해야지님.

여러 복잡한 비즈니스 로직과 개념이 얽혀 있는 경우, 개념 간의 경계가 불명확해질 수 있습니다. Order, Payment, Cancel 등의 개념은 각각의 역할과 책임을 명확히 하여 모듈화하는 것이 중요합니다.

경계의 모호함에 대한 이해:

1. 기능 확장 시 경계가 모호해질 수 있는 이유:

   • 다양한 기능이 추가될 때 각 개념의 역할이 불분명하면, 특정 기능이 어디에 속해야 하는지 결정하기가 어려워집니다. 예를 들어, ‘결제 취소’ 기능이 Payment나 Cancel 중 어디에 속해야 할지 모호할 수 있습니다.
     

2. 기능 확장이 경계 모호성에 영향을 미치는 방식:

   • 새로운 비즈니스 요구사항이 추가될 경우, 예를 들어, 새로운 결제 방식이 추가되거나, 취소 정책에 변화가 발생할 때, 각 개념이 자기 역할을 중심으로 확장되지 않는다면, 모든 변화가 Payment에 집중될 위험이 있습니다. 이는 코드 복잡성을 증가시키고 유지관리를 어렵게 만듭니다.
     

3. 해결 방안:

   • 각 개념의 책임을 명확히 정의하고 변경에 유연한 구조 설계를 해야 합니다. 예를 들어, Order는 주문 정보 관리, Payment는 결제 상태 관리, Cancel은 주문 취소와 관련된 로직을 처리하는 방식으로 책임을 분할할 수 있습니다.
     

아래 관련 질문 링크를 통해 더 깊이 있는 논의를 참고하실 수 있습니다:
- Cancel - 기능 확장을 바라보는 관점에서 질문 - 취소 매커니즘의 경계와 확장성에 대한 논의가 있음.
- 도메인 계층에서 의존 관계 관리 - 도메인 간 의존성과 확장성을 고려한 모듈화 사례.

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