DDD이란?

Domain Driven Design은 domain 중심의 설계를 말한다. 실제 개발을 하면서 많은 실제로 많이 드는 생각은 계층형 구조가 되기 힘들다는 점이다. 계층형 구조로 짜다보면 코드가 더 많아질 뿐더러 귀찮다는 점이 가장 크다. 하지만 계층형 구조와 domain을 구분하여 활용을 한다면 유지보수적인 면이나 개발한 코드리뷰를 할 때, 더욱더 많은 편리함을 누릴 수 있다.

DDD 구조

DDD는 세 가지의 큰 목차를 가지고 있다.

• Application
• Domain
• Infrastructure

세 가지의 목차에는 다음과 같은 요소들이 있다.

1. Application
   • Service
   • dto
   • repository
2. Domain
   • Service
   • entity
   • value
3. Infrastructure
   • 외부 연결

목차와 요소를 구분을 한다면 레이어가 이미 구분이 되어 있다는 말과 동등할 수 있다.

Application

Application 영역에서 보여지는 요소는 다음과 같이 설명을 할 수 있다.

• Service : Application의 로직, Use case 구현
• Repository : 객체 데이터 보관 창고, 데이터 저장 및 복원
• DTO : 데이터의 자료형 명시 및 로직

Domain

Domain은 엔티티나 값 객체가 할 수 없는 일을 대신한다. 예를 들어 user를 조회하여 내보내는 것에 대한 로직이 필요하다면 Domain에 명시가 된다.

• Value : 원시적인 타입 명시, 변하지 않는다.
• Entity : 도메인 모델 명시, 상태를 가지고 있으며 생명 주기를 가진다.
• Service : Domain Service 로직

정리

DDD를 도입하며 느낀 점음 개발자에게 가장 힘든 문서를 작성할 필요가 없을 수도 있겠다는 생각이 들었다. 개발자들에게 가장 어려운 영역이자 가장 지켜지지 않는 영역이 문서화라 생각이 든다. DDD로 작성을 하면 모든 것을 문서화를 시키지 않아도 되는건 아니지만 적어도 코드를 보며 어디에 어떤 부분이 있는지, 어디서 확인을 해야 되는지, 어떠한 함수와 어떠한 정보가 오고 가는지를 확인할 수 있다.

API를 만들다 보면 주변에서 많이 들려오는 말이 있을 것이다. 'REST 하다. REST 하지 않다.' 이러한 말들을 처음 들었을 때는 무슨 의미인지 파악하기가 힘들었다. 'API면 API지 REST하지 않다라는 말은 왜 하는거지.'이러한 생각들이 사무칠 때 쯤 REST API를 만든 로이 필딩의 논문을 보았다.

로이 필딩은 2000년에 REST API 아키텍처를 박사 논문으로 만든 사람으로써, Web설계 우수성에 비해 제대로 사용되지 못하는 안타까움으로 만들었다고 한다.

API는 다음과 같은 요소를 가지고 있다.

1. 자원 (Resource)
2. 행위 (Verb)
3. 표현 (Representation of Resource)

이러한 구성 요소를 가지고 REST스러운 API를 design하는 특징은 다음과 같이 적혀져 있다.

1. Uniform
   • 인터페이스 일관성
2. Stateless
   • 무상태성
3. Cacheable
   • 캐시 처리 가능
4. Self-descriptiveness
   • 자체 표현 구조
5. Client-Server
6. Layer System
   • Server에 대한 다계층 구조

API를 만들면서 가장 쉬우면서 지키기 어렵다고 생각한 부분은 Self-descriptiveness과 URI부분이었던 것 같다. 규칙을 지키기 가장 쉬우면서 가장 어려운 영역인 것 같았다. URI와 Self-descriptiveness의 규칙은 다음과 같다.

1. Self-descriptive 규척

• 메세지만 보고 명확해야 된다.
• 목적지가 명확해야 된다.

이러한 두개의 규칙이 주요 규칙이지만, 가장 많이 범하기 쉬운 규칙이다.

# Http 버전 명시와 성공이 되었을 때, 어떤한 코드로 오는지 명시가 되어야 된다.
GET HTTP/1.1 200 OK
# Client가 알기 위해선 목적지가 필요하다.
Host: https://www.example.com 
# Body의 내용을 Client가 알아야 된다.
Content-Type: application/json

{ "data" : "test data" }

위의 예제와 같이 보내질 경우 Self-descriptive하다 할 수 있다. Client가 API를 사용하기 위한 정보가 들어있기 때문이다. Client가 API를 사용하기 위해선 API의 주소를 알아야 된다. 또한, body에 담긴 내용이 어떠한 형식으로 오는지도 명시를 해야 Client가 사용을 할 떄, 불편함이 없다.

2. URI 설계

uri설계를 할 때, 가장 많이 범할 수 있는 부분은 uri에 동적인 부분이 들어갈 수 있는 것이다.

GET /read/user/info

위의 uri를 그대로 해석한다면 "user의 정보를 읽는 것을 가진다." 굉장히 어색하고, 불편한 uri이다. 심지어 읽기에도 불편하다. 당연히 동사가 두 번이나 들어가 있어서 읽기 불편한 요소가 된다.

GET /user/info

위의 uri를 해석하면 "user의 정보를 가져온다"가 된다. 보기만해도 어떠한 uri를 가지고 있는지 확실히 알 수 있어서 보기에도 좋다.

정리

uri 설계와 REST API를 설계할 떄, 많은 범용적인 실수와 당연한 것들에 대한 무시가 남무한다. 이러한 API는 REST하지 않다라고 말을 한다. 요즘에 나오는 대부분의 API들은 이러한 규칙을 지키지 않는다. 사실 만들고 나서 "우리만의 REST 규칙을 만든 것이다." 라고 하면 따질 말이 없지만, 그 전에 기본에 충실한 것이 가장 중요한 것이 아닐까란 생각이 든다.

그 중 flask를 사용한 이유는 Django보다 자유롭게 활용을 할 수 있기 때문이다. 모든 것이 짜여져 있는 Django의 특성을 활용을 한다면 처음 API를 사용하기엔 아주 최적화 되어 있다고 생각을 하지만, 직접 API를 디자인하기엔 무리가 있다 판단을 하여 보다 자유로운 flask를 사용했다.

직접 디자인을 하고 설계를 할 시, 보다 API 설계에 대한 이유와 중요성을 빠르게 이해를 할 수 있어 직접 디자인을 선택했다. 다른 프레임 워크에서도 디자인이 가능하지만 자유로운 flask를 선택 함으로써 처음부터 디자인을 하며 API 설계와 디자인을 자신의 것으로 만들 수 있기 때문이다. 고로 이 설계 방식은 DDD(Domain Driven Design)을 이용하여 만들었지만, 정답은 아니다. API는 DDD(Domain Driven Design)를 사용하여 설계를 하였으며, 모든 것은 기획 의도에 맞게 설계가 된다. 여기서 '기획 의도에 맞게 설계가 된다.'는 모든 API들은 기획 의도에 벗어나지 않게 구현이 되지만, client(API 사용자) 입장에 맞춰 더 편하게 사용할 수 있는 API를 구현하는 이유이다.

API 스펙은 다음과 같다.

• 사용 언어 : python3.9
• 웹 프레임 워크 : Flask 1.1.2
• IDE : VScode
• Design : DDD(Domain Driven Design)
• DB : Firebase