1.
- 고도로 특화된 좁은 도메인 서비스가 유스케이스 하나씩만 담당하는 것으로 ‘넓은 서비스’문제를 완벽하게 해결할 수 있다고 생각하시는지 궁금하다. 저는 사실 이 사항에 대해 □□□service라는 네이밍 그 자체에 문제가 있다고 생각한다. 아래와 같은 이유로...
- 이 네이밍 자체가 서비스의 너비를 넓히고, 많은 책임을 섞이게 만든다고 생각한다. 너무 넓은 범위를 아우르기 쉬운 네이밍인 것 같다. → 이 부분에 대해서 고도로 특화된 좁은 도메인 서비스 네이밍을 잘하면 해결된다고 생각할수도 있을 것 같다.
- 위 처럼 고도로 특화된 좁은 도메인 서비스가 필요하다는 개념이 잡히지 않은 개발자가 팀의 합류한다면? 그 사람이 과연 Service라는 네이밍이 붙은 클래스를 보며 무슨 생각을 할까?
- 고도로 특화된 좁은 도메인 서비스를 만들까?
- 또 UserService 같은 것들이 애플리케이션 전체적으로 퍼지게 될 가능성이 높아진다고 생각한다.
→ 저는 이러한 이유들로 인해 □□□service라는 ****네이밍 그 자체에 문제가 있다고 생각합니다. 다시 원래 질문으로 돌아와서 발표자 분께서는 고도로 특화된 좁은 도메인 서비스가 유스케이스 하나씩만 담당하는 것으로 ‘넓은 서비스’문제를 완벽하게 해결할 수 있다고 생각하시는지, 아니면 저처럼 다른 견해가 있으신지 발표자님의 생각이 궁금합니다.
→ 답변 : 그 선을 찾는 것이 매우 어려운 일인거 같다! 나중에는 이것까지 쪼개야해? 라는 생각이 들듯! 어느정도만 쪼개고 문제가 생기면 그때 필요성을 느끼고 쪼개는 것도 매우 좋은 방안이라 생각한다!
2.
- 또한 인커밍 포트의 경우 진입점이라는 아키텍처 상의 명목을 제외하고는 실제로 그 필요성이 의문이다.
- 굳이 인커밍 포트가 존재하지 않아도 의존성 방향의 문제가 전혀 없고 아무리 봐도 인커밍 포트는 아키텍처의 구조를 맞추기 위해서만 쓰이지, 실제로 실효성이 없어보인다. 그저 패키지 구조를 더 복잡하게 만들고 불필요한 인터페이스 늘어나기만 할 것이라고 생각한다. 또한 그로 인해 오히려 유지보수하기 더 힘들어지기만 하지 않을까..!
→ 이 생각에 따라서 인커밍 포트의 실효성에 관해 질문하고 싶다. 인커밍 포트가 내가 말한 부분을 감안하고서라도 필요하다고 생각하는지, 그렇게 생각한다면 어떠한 이유에서 그렇게 생각하는지
→ 답변 : 인커밍 포트의 필요성
- 듣다보니 그 진입점 자체로서의 역할, 클라이언트 입장에서 필요한 기능만 볼 수 있는 그 역할 자체도 매우 클 수 있겠다고 생각된다!
- 임의의 구현체를 통해 모킹 없이도 테스트 가능하다!