비지니스로직 분리 질문드려요!

하나의 파일에 하나의 로직을 담아야하는지, export를 여러개 두어도 되는지는 상황이나 취향에 따라 다를 수 있습니다. 다만 비즈니스로직과 관련하여서는 hook 뿐만 아니라 대부분의 코드도 크게 두가지로 분류하여 생각할 수 있습니다. 1. 비즈니스 맥락과 관련없이 사용할 수 있는 코드 2. 비즈니스 맥락과 깊은 연관이 있는 코드 훅으로 예를 들면 debounce, throttle 기능을 제공하는 훅은 비즈니스 맥락과 관련없이 디바운싱이나 스로틀링이 필요한 모든 곳에서 사용할 수 있을 것입니다. 반면 비즈니스 맥락과 깊게 연관을 가지는 코드도 있을 수 있습니다. 예를 들면 내 사이트의 장바구니와 관련된 훅이 있을 수 있습니다. 당연히 모든 애플리케이션이 장바구니를 사용하지도 않을뿐더러 내 프로젝트의 구조에 맞는 특정 데이터구조를 담고있을 장바구니를 다루는 훅은 나의 비즈니스와 깊게 연관이 있으면서 다른 곳에 그대로 이식할 수 없는 코드일 것입니다. 여러가지 요구사항을 반영하는 프론트엔드 코드를 짜다보면 자연스럽게 코드의 복잡도가 올라가게 됩니다. 이는 비즈니스로직과 그 비즈니스로직을 외부 API 혹은 기능과 적절히 녹여내기 위해 복잡해지는 경우가 대부분인데요 예컨대 앞서 말했듯이 기능을 구현하다보면 디바운싱 스로틀링이 필요한 기능이 있을 수 있습니다. 이런 경우 디바운싱 스로틀링 기능을 추상화하지 않으면 비즈니스로직과 디바운싱 스로틀링을 구현하기위한 클로저, 셋타임아웃 코드들이 혼재되면서 코드복잡도가 높아지게 됩니다. 그런데 만약 비즈니스로직과 이런 UI 혹은 유틸리티성 기능들이 끈끈하게 결합되어있다면 어떨까요? 코드를 관리하기도 어려울거고 코드의 의도를 파악하기도 어렵겠죠? 이렇듯 프론트엔드 개발에서 비즈니스 로직을 고민할 때에는 특정 기능에서 내 프로젝트의 맥락에만 존재하는 "비즈니스로직"인 것과 그렇지 않은것을 적절히 구분하고 그 둘을 격리하여 구현하는 것이 중요합니다. 이것을 의식하면서 코드를 작성해보시고 조금 더 관심이 생긴다면 클린아키텍처, Feature Sliced Design과 같은 키워드를 검색해보시면 좋을 것 같습니다.