개발자

클린아키텍처에서 Application 레이어는 꼭 필요할까요?

4월 9일조회 49

클린+레이어드 아키텍처를 공부하면서 Usecase와 Facade 같은 Application 레이어에 대해서 처음 알게되었습니다. 처음엔 하나에 모아서 service들을 호출할 수 있네? 좋잖아? 라는 생각이었는데, 실제로 코드를 작성하다보면 단순 서빙만을 하는 경우가 더 많아서 복잡성만 증가하는 느낌을 받은 적이 있습니다. 저는 개인적으로 MSA 에서는 Event로 도메인간 연결이 이뤄지니까 Application 레이어가 오히려 코드 복잡성만 높히지만, Monolithic에서는 유의미하게 동작하는 것 같습니다. 그래서 Application 레이어는 아키텍처에 따라 선택될 수 있지 않을까? 라고 생각이 들더라고요. Application 레이어의 유무가 꽤나 논쟁이 있는 주제라고 들었는데, 여러분은 어떻게 생각하시나요?

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.

답변 0

답변이 없을 때 보이는 아이콘

첫 답변을 기다리고 있어요.

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

AI 답변
커리어리 AI 봇 프로필 이미지

커리어리 AI 봇

GPT가 달아주는 답변입니다.

4월 9일

클린 아키텍처에서 Application 레이어는 비즈니스 로직의 순서와 프로세스를 정의하는 중요한 역할을 합니다. 이 레이어는 도메인 레이어에서 정의된 비즈니스 규칙을 사용하여 사용자나 외부 시스템이 요구하는 비즈니스 연산을 수행하게 됩니다. 그러나 말씀하신대로, 만약 단순 서빙만을 목적으로 한다면 이 레이어가 오히려 복잡성을 증가시키는 원인이 될 수 있습니다. 이런 경우에는, 해당 서비스의 필요성과 복잡성에 따라 구조를 단순화 하는 것도 방법일 수 있습니다. 그리고 MSA(Microservices Architecture)와 Monolithic Architecture 에서 각각 Application 레이어의 필요성은 다를 수 있습니다. MSA에서 각 마이크로서비스는 독립적으로 배포되고 운영되기 때문에, 각 마이크로서비스 내부 구조는 단순하게 유지하는 것이 일반적입니다. 반면, Monolithic Architecture에서는 애플리케이션 전체를 하나의 단위로 관리하기 때문에, 좀 더 복잡한 내부 구조가 필요할 수 있습니다. 이 경우 Application 레이어는 복잡한 비즈니스 프로세스를 관리하고, 여러 도메인 간의 흐름을 조정하는 역할을 합니다. 결론적으로, Application 레이어의 유무는 사용하는 아키텍처와 서비스의 복잡성, 팀의 선호 등에 따라 결정될 수 있다고 생각합니다. 이에 대해 '항상 필요한 것'이 아니라 '상황과 요구사항에 따라 선택되어야 하는 것'이라는 것이 제 개인적인 견해입니다.

목록으로

지금 가입하면 모든 질문의 답변을 볼 수 있어요!