Typescript로 설계하는 프로젝트 "같은 로직 또 복사했어요?" Domain 모델로 책임 분리하기
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
아키텍처 패턴과 설계 원칙
대상자
- *개발자** _TypeScript 및 도메인 모델 설계에 관심 있는 중급 이상 개발자_
핵심 요약
- 문제점 : Service에 모든 로직 집중 → 파일 비대화, 응집도 부족, 확장성 제한
- 근본 원인 : 타입과 로직이 분리되어 도메인 로직이 분산됨
- 해결 방향 : 도메인 모델 도입으로 관련 로직 응집, User 객체에 상태 판단/권한 검증 로직 캡슐화
섹션별 세부 요약
1. Service 비대화와 응집도 부족 문제
- Service 파일의 비대화 : 사용자 관련 함수들이 여러 곳에 흩어짐
- 도메인 지식 분산 : "사용자가 할 수 있는 것"에 대한 로직이 여러 곳에 흩어져 있음
- 확장성 제한 : 새로운 기능 추가 시 Service 수정 필요
2. 타입 중앙 집중화와 도메인 모델 중앙화
- 타입 중복 문제 해결 :
shared/domain
디렉토리에 타입 정의 통일 - Type-Driven Development :
User
타입 변경 시 컴파일러가 자동으로 관련 코드 검증 - BFF 패턴에서의 타입 활용 : 여러 API 조합 시 타입 안정성 보장
3. 도메인 모델로의 전환: User 클래스 구현
- 도메인 모델 로직 이동 :
getStatus()
,canWritePost()
등 사용자 자체의 상태 판단/권한 검증 로직 캡슐화 - Service의 역할 재정의 : 외부 의존성(예:
userRepository
,notificationService
) 처리 및 복잡한 협력 로직 처리 - Mapper 패턴 고려 : API 응답과 도메인 모델 구조가 다를 때의 변환 전담
4. 함수형 vs. 객체지향 접근 방식 선택 기준
- 함수형 장점 : 학습 용이, 테스트 간편, 불변성 보장
- 객체지향 장점 : 로직 응집, 확장성 우수, 캡슐화 가능
- 하이브리드 권장 : 복잡한 상태 관리 및 확장성이 필요한 경우 객체지향, 단순 로직은 함수형
결론
- 도메인 모델 설계 핵심 팁 :
- 사용자 관련 상태 판단/기본 권한 검증은
User
객체에 캡슐화 - 외부 의존성 처리 및 여러 도메인 협력 로직은
UserService
에 구현 - Mapper 패턴을 통해 API 응답과 도메인 모델 간 변환 관리
- 함수형과 객체지향 접근 방식을 프로젝트 복잡도와 팀 역량에 따라 적절히 선택해보세요.