[크리스마스 프로모션] 코드 리뷰 #1
Conversation
- 요청상황에 맞는 답변을 추가함
| var clientService = new ClientService(); | ||
| var menuOrderService = new MenuOrderService(); | ||
| var ioController = new IOController(new InputView(),new OutputView()); | ||
| PlannerController plannerController = new PlannerController(ioController,clientService,menuOrderService); |
There was a problem hiding this comment.
Controller가 Controller를 (또는 Service가 Service를) 의존하는 방식은 일반적으로 권장되지 않는 것으로 알고 있습니다. 가장 큰 이유가 규모가 커지면 순환 참조가 일어날 여지를 남기게 되고 이를 예방하려면 서로 간의 계층을 뚜렷하게 나누어야 하는데 방법이 마땅치 않다는 점에 있습니다. 이 부분 어떻게 생각하시는지 의견 나누어보고 싶어요.
There was a problem hiding this comment.
(일단 질문을 받아 드는 생각을 적었지만 내일까지 다시한번 생각해보겠습니다ㅎㅎ)
Front controller 의 역할을 하는 디스패처 서블릿이 있다라는 것을 생각하여 io 컨트롤러의 경우 Front 의 코드라고 생각을 하였습니다. 메인이 될 어플리케이션 로직을 담당하는 컨트롤러인 PlannerController 에서 도메인 모델을 다루지 않는 IO 컨트롤러를 호출해도 순환은 안할것 같다라고 생각을 했습니다.(클라스 이름을 다시한번 고민해보겠습니다 !!)
서비스의 경우 관리하는 도메인의 영역이 커지면 인터페이스를 통하여 서로 참조하는 방식으로 개발을 할것이라고 생각합니다.
순환참조의 오류를 가질수 있지만 , 하나의 서비스에서 다른 도메인들의 레포지토리를 호출하게 되면 도메인간의 분리가 더 어려울 것 같다라고 생각합니다.
계층간의 분리 즉 컨트롤러 , 서비스 , 도메인 모델 , 레포지토리의 경계를 나누는 것은 동의하는 입장입니다.
도메인간의 서비스 계층은 같은 계층으로 이해를 하여 단방향으로 호출하는 상황은 괜찮다라고 생각합니다.
실제 restapi 를 지원하는 어플리케이션의 경우 언급해 주신 것처럼 서로 컨트롤러 간에 의존하지 않고 개발을 할것 같습니다.
src/main/java/christmas/back/application/usecase/CheckEventAndUpdateClientPayment.java
Show resolved
Hide resolved
도메인간의 의존성 하나만 생각하여 작성한 코드입니다.
유즈케이스에서 이벤트들의 적용을 처리하거나, 사용자 정보를 저장합니다.
레이어드 아키택처 사용 이유 : 도메인간의 결합을 낮추기 위하여 객체의 고유식별자를 통하여 객체를 찾기위하여 도입하였습니다.
magic number 처리 부분과 관련해서는 리뷰안해주셔도 됩니다.
리뷰 요청 사항 : 더 나은 설계 방식이 있는지 궁금합니다.