도메인 주도 설계(DDD, Domain-Driven Design)는 복잡한 비즈니스 도메인을 효과적으로 모델링하고 개발하기 위한 접근 방식입니다.
특히 비지니스로직을 철저하게 분리함으로써 코드가 각각의 역할에 집중을 할 수 있게 해주며, 서버 프로그래밍을 하시는 분 들은 대부분 해당 전략을 사용 합니다.
프론트 또한 단순한 도메인이라면 상관 없겠지만 "은행", "병원" 같은 정말 많은 데이터가 관리 되어야 하는 프로젝트에서 각종 알 수 없는 조건문과 케이스가 복잡하게 난도질 되어 있다면 ddd를 적용 함으로써 완벽하게 비지니스 영역과 화면(뷰, view)영역을 분리하는 것이 향후 유지보수에 좀더 용이하다 할 수 있겠습니다.
ddd 패턴을 적용하려면 철저하게 비지니스 로직 영역에 적용을 해야 합니다.
이번에 적용 해본 방식은 아래와 같습니다.
1. 컴포넌트 영역 : 화면 변화에 대한 상태 관리, 서비스 또는 유스케이스 객체를 적용하는 구간
2. 페이지 영역 : 컴포넌트를 불러오는 영역
3. 비즈니스 영역 : 데이터를 처리하는 구간, 해당 구간 코드를 DDD 형태로 분리
컴포넌트 영역에서는 만들어진 유스케이스 또는 서비스 객체를 가져와 데이터를 처리하도록 합니다.
또한 useState나 기타 상태, 컨텍스트 처럼 가공된 데이터를 가지고 동작하는 구간을 정의 합니다.
다음으로 페이지 영역은 ssr에 사용되는 코드나(예 : getServerSession 같은) 컴포넌트를 불러오는 코드 또는 정적(static) 컨텐츠와 관련된 내용만 존재 합니다.
물론 프리패칭 전략이나 캐싱같은 전략을 적용 해도 상관 없습니다.
가장 중요하고 어려운 비즈니스를 분리한 DDD 영역 입니다.
비즈니스를 분리한 영역에서는 가장 먼저 도메인을 설계하여 줍니다.
아래는 간단하게 계시판이라는 프로젝트에서의 도메인 영역 입니다.
이렇게 만든 도메인 객체를 사용하는 레포지토리를 인터페이스(interface)로 구현을 해 줍니다.
인터페이스로 레포지토리를 구현하는 이유는 향후 레포지토리를 사용하는 서비스를 구현 할 때 레포지토리를 모킹(mocking)용도로 사용 할 수도 있기 때문 입니다.
확장성을 위해 인터페이스로 구현하는 것이 일반적인 관례라고 생각 합니다.
인터페이스를 상속받은 impl 형태의 클래스를 만들어 줍니다.
인프라영역(infrastructure)으로 불리우는데, 상속 받을 때 각종 행동요령을 정의하면 됩니다.
마지막으로 서비스 클래스를 만들어 줍니다.
서비스 클래스는 어플리케이션(application) 영역에 위치하는데, 리포지토리를 받을 때 인터페이스를 받게 하여 리포지토리가 다른 객체로 들어오더라도 확장성있는 형태가 되도록 해 줍니다.
요렇게 만들어진 서비스 클래스는 클라이언트 컴포넌트에서 호출하여 사용하면 됩니다.
저는 아래와 같이 action 이라는 파일을 만들어 브릿지 코드를 생성하고, 생성된 브릿지 코드를 다른 뷰 컴포넌트에서 사용하도록 하였습니다.
DDD로 분리를 하면서 고려해야되는 가장 중요한 점은 해당 서비스(유스케이스) 영역이 클라이언트에서 호출되는지 아니면 서버에서 호출되는지를 고려해야 된 다는 것 입니다.
간단하게 고려해야되는 점을 살펴 보면,
클라이언트에서 호출하는 코드에 fs 라든지 db커넥션 같은 코드가 있다면 당연히 오류가 나게 될 것 이고,
서버에서 호출하는 코드에 http를 활용한 fetch가 존재한 다면 요청하는 주소에 prefix 가 있는지 여부가 중요하게 될 것 입니다.
이렇게 DDD 형태로 만들고 나면 장점과 단점이 명확해 지는 것 같습니다.
1. 장점
가) 비즈니스 로직이 분리되어 코드가 간결해 진다
나) 데이터가 변경되거나 추가되면 고쳐야하는 엔드포인트가 찾기 쉬워진다
다) 뷰코드에서 조건문이 확연하게 줄어든다
2. 단점
가) 그냥 단순 게시판 하나 만드려고 했는데 너무 오래걸린다
나) 서버, 클라이언트 영역 등 각종 영역을 고려하여 ddd 를 설계해야.. 난이도가 높다ㅠ
정말 큰 서비스를 만약 계획한다면 ddd는 이제 선택이 아니라 필수인 것 같습니다.
확연히 유지보수에 장점이 훨씬 많아보이며, 코드 컨벤션도 지키기 매우 수월해 보입니다.
그렇지만 생산성, 공장에서 찍어내는 듯한 퍼포먼스를 기대하기에는 매우 복잡하기에, 이러한 부분은 고려되야 합니다.
아래는 해당 ddd 구조를 따라 만들어본 git 페이지 입니다.
https://github.com/TaeSeungRyu/my-next-js
GitHub - TaeSeungRyu/my-next-js: nextjs 연습 리파지토리 입니다.
nextjs 연습 리파지토리 입니다. Contribute to TaeSeungRyu/my-next-js development by creating an account on GitHub.
github.com
거대한 어플리케이션을 계획하신다면, 한번쯤 해 볼만한 것 같습니다!
감사합니다.
'앵귤러, 리엑트, 뷰' 카테고리의 다른 글
| 열심히 만져본 next와 nuxt (1) | |
|---|---|
| SPA 환경에서 배포가 이루어 졌을 때 새로 고침 방법 (1) | |
| 'ImportMeta' 형식에 'env' 속성이 없습니다. (1) | |
| [Vite] Vite 개발 환경에서 타입스크립트(Typescript) 적용하기 (0) |
댓글