inflearn logo
강의

Course
Instructor

Gemini's Development Practice - Commerce Backend Basics

Product Details - Feeling the Code

표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.

Resolved

123

back47402311

2 asked

1

안녕하세요 제미니님, 유튜브부터 계속 꾸준히 보다가 강의 릴리즈 하신 후 바로 구매하여 듣고 있는 사람입니다. 먼저, 생각할 거리를 많이 주는 좋은 강의 감사드립니다.

 

다름이 아니라, 일단은 ProductSerivce 안에서 Product라는 개념만을 명확히 다루고자 하였기에 Controller에 타 개념의 Service들도 혼재되는? 그런 상황이라고 이해했습니다.

 

물론 다 선택의 영역이겠지만, 개발자분들 중에선 Presentation 영역(Controller)을 최대한 가볍게 가지고 가시려는 분들도 많은것 같습니다.

그래서 대신에 여러 서비스들이 혼재되는 상황을 Facade 등을 도입해서 여러 개념의 서비스들에 대한 presentation 계층에서의 접근을 일원화하고 각 서비스단에서의 복잡성은 해결하고자 하는 케이스도 실무에서 종종 접했는데요. 이에 대해서는 제미니님께서 어떻게 생각하시는지 궁금합니다.

kotlin spring-boot 도메인 dbms/rdbms backend

Answer 2

0

geminikims

안녕하세요! 질문 감사드립니다
유사한 질문에 대한 답변이 있어서 링크 전달드립니다!

혹시 보시고 추가 질문이 있다면 주시면 감사하겠습니다!

0

communityai8509

안녕하세요, 인프런 AI 인턴입니다. 백지훈님.

좋은 질문을 해주셔서 감사드립니다. 백엔드 개발에서의 프리젠테이션 레이어는 사용자 요청을 처리하고, 적절한 비즈니스 로직으로 이어주는 중요한 부분입니다. 이 과정에서 여러 서비스가 혼재될 수 있는데요, 이를 효율적으로 관리하기 위한 디자인 패턴이 ‘파사드(Facade)‘입니다.

파사드 패턴과 프리젠테이션 레이어 관리

  1. 파사드 패턴의 장점:

    • 복잡성 감소: 여러 서비스들을 하나의 인터페이스로 묶음으로써, 프리젠테이션 레이어는 단순화됩니다. 이는 유지보수성을 높이고, 코드의 가독성을 향상시킵니다.
    • 일관성 유지: 각각의 서비스 로직이 변화하더라도, 파사드 인터페이스는 이를 캡슐화하여 프리젠테이션 레이어에 미치는 영향을 최소화합니다.
    • 확장성: 새로운 기능을 추가할 때, 기존 프리젠테이션 레이어를 그대로 두고 파사드만 수정함으로써 시스템을 쉽게 확장할 수 있습니다.

  2. 프리젠테이션 레이어의 접근 방식:

    • 표현 계층을 가볍게 유지하는 접근법은 코드의 명확성을 위해 권장됩니다. 컨트롤러는 단순히 사용자 요청을 받아 적절한 서비스 메서드를 호출하는 데 집중해야 합니다.
    • 파사드를 도입하면 복잡한 비즈니스 로직이나 여러 서비스 호출을 컨트롤러에서 분리하여, 프리젠테이션 레이어의 코드를 간결하게 유지할 수 있습니다.

제미니님의 강의에서는 이러한 점을 기반으로 파사드 패턴의 사용이 습관적으로 남용되지 않고, 필요한 경우에 적용되어야 한다는 점을 설명하고 있습니다.

여기에 대한 더 많은 실전 적용 사례나 논의를 보고 싶으시다면, 다음과 같은 유사한 질문과 답변이 도움이 될 수 있습니다:

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

다양한 관점의 코드 경험을 위해 개선하지 않은 코드

1

47

1

histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/

1

44

2

SettlementTargetRepository Jquery 질문

1

48

2

부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?

1

60

2

엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??

1

67

2

제미니님 안녕하세요!

1

73

2

개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조

1

80

2

프로덕트와 프로덕트카테고리 사이의 삭제 정책

1

75

2

새로 개발한다면 구현 순서

1

133

1

의존 방향에 대한 고민

1

122

2

어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?

1

95

2

OrderKeyGenerator 인스턴스화 generate() 질문

1

83

1

외부 API 통합 시 데이터 제어 범위 설계 질문

1

96

1

PG 결제 승인 로직

1

128

2

QnA에서 Join 필드 표현법

1

88

1

결제서비스 콜백 동시성문제 가능성

1

106

2

굿

1

107

1

도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법

1

135

2

도메인 객체와 엔티티 객체 사용

1

137

2

CouponService 의존성 의문

1

96

2

상품 목록 조회 고도화 질문

1

111

2

제품상세 코드 느끼기

1

144

2

격벽의 순환 참조(?)

1

113

2

결제 관련 서킷 브레이커 전략, 데이터 정합성 및 타임아웃 설정 질문

2

174

2