[이전 안내] "원래 있던 기능이니 금방 하시죠?" 당하지 않는 Service Layer 설계 전략 With Di
기획자: "별거 아니에요! 사용자의 특정 조건에 따라 카드 색깔만 바꾸면 되는데, 기존에 있던 기능이니 금방 하시죠?"
나: (그거 컴포넌트 로직에 딱 붙여놨는데... 또 복사해서 써야 하나? 😰)
이런 상황에서 우리를 구원해 줄 방법은 바로 Service Layer를 분리하고 DI(의존성 주입)를 도입하는 것입니다. 비즈니스 로직을
UI와 API 호출부에서 독립시키면, 어떤 갑작스러운 요구사항에도 "네, 금방 됩니다!"라고 당당하게 말할 수 있습니다.
⚡️ 이 글에서 다루는 핵심 내용
-
관심사의 분리: UI 렌더링, CSS 스타일링, 비즈니스 로직을 완벽하게 떼어내는 법
-
재사용성 극대화: 한 번 작성한 상태 판단 로직(getUserStatus)을 앱 어디서든 호출하는 법
-
의존성 주입(DI): 외부 서버 인터페이스를 주입받아 테스트하기 쉽고 유연한 코드를 만드는 법
-
코드 레벨의 BFF: 여러 API를 조합하여 프론트엔드에 최적화된 데이터를 가공하는 전략
상세한 클래스 설계 코드와 테스트 작성법, 그리고 복잡한 요구사항을 해결하는 실전 예제는 아래의 새로운 블로그에서 확인하실 수
있습니다.👉 글 전체 읽으러 가기: Service Layer 설계 전략 With Di
(https://blog.sangwook.dev/posts/typescript-project-service-di-design)
4개의 댓글
저는 이번 편이 상욱님의 시리즈 중 가장 인상 깊었습니다.
개발을 하다 보면 항상 고민되는 부분이 "이 로직은 어디에 위치해야 하지?", "이건 유틸로 뺄까, 도메인에 포함시킬까?" 같은 경계의 문제였어요. 특히 프로젝트가 커질수록 비즈니스 로직을 어디에 어떻게 배치해야 확장성 있고 재사용 가능한 구조가 될지 막막했는데, 이번 글을 통해 그 실마리를 조금 잡은 느낌입니다.
결국 돌고 돌아 마주치는 "어, 이거 기존에 만든 거 또 만들었네요?" 같은 문제도 도메인 모델의 책임 분리로 자연스럽게 해결할 수 있다는 게 크게 와닿았습니다. 좋은 글 정말 감사합니다! 🙌
와우..... 이글에 지금까지의 모든 것이 다 담겨있네요.
글을 쭉 보면서 스스로 어떻게 개발하고 있는지 생각하게 되는 것 같아요.
해당 시리즈의 내용들을 바로 사용하지는 못하겠지만, 좋은 간접경험 가져갑니다!