DDD를 도입하게 된 이유는 API를 설계를 여러번 하면서 느낀 점이 정리가 되지 않는 다는 느낌이 많이 들었다. 필요한 부분은 미리 다 작성해 놓고, 미리 다 만들어 놓은 다음 쓰면 더 편할 것 같은 느낌이 든 적이 굉장히 많다. 만약 중앙 집중적인 형태를 좋아하거나, 필요한 함수나 필드명 혹은 중복되어서 사용하는 모든 것들을 관리하고 싶은 사람이라면 DDD를 도입하는 것을 굉장히 좋아할 것이라고 생각이 든다.
DDD이란?
Domain Driven Design은 domain 중심의 설계를 말한다. 실제 개발을 하면서 많은 실제로 많이 드는 생각은 계층형 구조가 되기 힘들다는 점이다. 계층형 구조로 짜다보면 코드가 더 많아질 뿐더러 귀찮다는 점이 가장 크다. 하지만 계층형 구조와 domain을 구분하여 활용을 한다면 유지보수적인 면이나 개발한 코드리뷰를 할 때, 더욱더 많은 편리함을 누릴 수 있다.
DDD 구조
DDD는 세 가지의 큰 목차를 가지고 있다.
- Application
- Domain
- Infrastructure
세 가지의 목차에는 다음과 같은 요소들이 있다.
- Application
- Service
- dto
- repository
- Domain
- Service
- entity
- value
- Infrastructure
- 외부 연결
목차와 요소를 구분을 한다면 레이어가 이미 구분이 되어 있다는 말과 동등할 수 있다.
Application
Application 영역에서 보여지는 요소는 다음과 같이 설명을 할 수 있다.
- Service : Application의 로직, Use case 구현
- Repository : 객체 데이터 보관 창고, 데이터 저장 및 복원
- DTO : 데이터의 자료형 명시 및 로직
Domain
Domain은 엔티티나 값 객체가 할 수 없는 일을 대신한다. 예를 들어 user를 조회하여 내보내는 것에 대한 로직이 필요하다면 Domain에 명시가 된다.
- Value : 원시적인 타입 명시, 변하지 않는다.
- Entity : 도메인 모델 명시, 상태를 가지고 있으며 생명 주기를 가진다.
- Service : Domain Service 로직
정리
DDD를 도입하며 느낀 점음 개발자에게 가장 힘든 문서를 작성할 필요가 없을 수도 있겠다는 생각이 들었다. 개발자들에게 가장 어려운 영역이자 가장 지켜지지 않는 영역이 문서화라 생각이 든다. DDD로 작성을 하면 모든 것을 문서화를 시키지 않아도 되는건 아니지만 적어도 코드를 보며 어디에 어떤 부분이 있는지, 어디서 확인을 해야 되는지, 어떠한 함수와 어떠한 정보가 오고 가는지를 확인할 수 있다.
