TypeScript로 도메인 모델로 책임 분리해보세요

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 응답과 도메인 모델 간 변환 관리
  • 함수형객체지향 접근 방식을 프로젝트 복잡도와 팀 역량에 따라 적절히 선택해보세요.