Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2단계 - 주문 기능 구현] 테오(최우성) 미션 제출합니다. #91

Merged
merged 103 commits into from
Jun 10, 2023

Conversation

woosung1223
Copy link
Member

@woosung1223 woosung1223 commented Jun 5, 2023

안녕하세요 서브웨이~!! 🥙 레벨2에서 또 뵙게 되었네요

이번에는 테코톡 준비로 바빠 미션에 원하는 만큼 투자하지 못한 것 같아서 아쉽습니다.
그래도 할 수 있는 최선을 다한 뒤 리뷰 요청을 보내지만 아직 부족한 점이 많을 것이라 생각해요.

대부분의 고민사항은 README에 적어두어서 해당 부분을 참고하시면 좋을 것 같은데요,
자력으로는 해결하기 어렵거나 서브웨이의 의견을 여쭙고 싶은 질문들은 여기에 작성하려고 합니다!
편하게 답변해주시면 감사하겠습니다 😄

질문

  1. 서비스와 도메인 엔티티의 관계에 대한 질문입니다. 이번 미션에서 가장 많이 신경 쓴 부분은, 서비스는 도메인이 할 수 없는 일만 한다입니다. 의식적으로 서비스 - 도메인 엔티티 책임을 분리하려고 노력했고, 대부분의 로직을 도메인 엔티티에 격리시켰다고 생각하는데요, 이런 관점으로 서비스 구현에 접근하는 것이 맞을지 궁금합니다. 제대로 책임을 분배한 것이 맞을까요?

  2. 예외의 책임에 대한 질문입니다. 프론트엔드와 협업을 진행하게 되면서 예외를 어떻게 사용해야 할지 고민이 되는데요! 예외가 이제는 디버깅적 측면이 굉장히 강해졌다고 생각하는데, 굳이 클라이언트 친화적인 메세지를 전달해야 할 필요가 있을까? 라고 느껴집니다. 물론 클라이언트에게 직접적으로 전달이 되어야 하는 예외도 존재하겠지만, 그렇지 않은 예외들은 디버깅을 고려해 개발자 친화적인 메세지를 전달해도 괜찮을까요? 예를 들면 리스트의 몇번째 인덱스에서 예외가 발생했습니다 등의 메세지가 있을 것 같습니다.

  3. 서버와 클라이언트의 관계에 대한 질문입니다. 이번 협업 미션을 진행하면서 UX적인 측면을 고려해 적립될 포인트는 클라이언트가 미리 계산해 사용자에게 보여주고, 주문을 발행할 때 이 정보를 같이 전송해 서버에서 계산한 값과 일치하는지를 판단했습니다. 그리고 이 로직은 자연스레 서비스에 위치하게 되었는데요. 이 과정에서 걱정이 드는 부분은, 서비스와 클라이언트의 결합도가 높아지지 않을까? 입니다. 서비스 재사용도 불가능할 뿐더러, 특정 컨텍스트에 묶이게 되기 때문입니다. 하지만 그렇다고 해서 모든 연산 책임을 서버가 가져버리면 UX는 급격하게 떨어지게 됩니다. 사용자는 주문을 하고 조금 기다려야 적립될 포인트는 얼마인지 볼 수 있을거에요. 적정선은 어디일지 고민이 됩니다. 이런 구조는 장기간 유지보수하기가 어려울 것 같은데... 서브웨이 생각은 어떠신가요?

이번에도 좋은 리뷰 부탁드립니다 감사합니다! 👍 커밋 링크 -> 커밋

`order` 예약어 이슈
@woosung1223 woosung1223 force-pushed the step1 branch 6 times, most recently from 62d0540 to 18513c6 Compare June 8, 2023 06:41
Copy link

@joseph415 joseph415 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

안녕하세요 테오.

리뷰 잘 적용해주셨네요💯
디엠으로 공유주신 Readme 확인했는데, 정말 열심히 하는것 같아서 저도 자극이 되네요👍

리뷰 적용한 코드들은 확인하였고, 잘 적용해 주신 것 같아서 따로 추가 코멘트는 안 남겼어요~!
첫번째 리뷰에서 resolve conversation 되지 않은 것들 추가로 답변 달아두었습니다. 확인 부탁드려요!


@Override
public FilterReply decide(ILoggingEvent event) {
String loggerName = event.getLoggerName();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logger Name은 무엇이들어가고 어디서 설정하나요!?

Copy link
Member Author

@woosung1223 woosung1223 Jun 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logger의 경우 생성 시점에 이름을 지정해줄 수 있는데요!

    private static final Logger logger = LoggerFactory.getLogger(ControllerExceptionHandler.class);

위와 같이요. 이 경우에는 해당 클래스의 path가 Logger 이름으로 지정됩니다.(cart.presentation.ControllerExceptionHandler)
물론 Logger 이름을 아무렇게나 String 형식으로 집어넣어도 되지만(아래처럼)

    private static final Logger logger = LoggerFactory.getLogger("로거입니다");

일반적으로는 해당 클래스의 Path를 사용하는 것 같습니다.

그리고 라이브러리는 어떤 방식으로 Logger name을 지정하나 궁금해져서 springBoot 코드를 살펴보았는데,
path를 통해 Logger 이름을 지정하는 방식을 사용하는 것 같았습니다!

public class ApplicationAvailabilityBean
		implements ApplicationAvailability, ApplicationListener<AvailabilityChangeEvent<?>> {

	private final Log logger;

	public ApplicationAvailabilityBean() {
		this(LogFactory.getLog(ApplicationAvailabilityBean.class));
	} 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants