기존 아키텍처 이해
DDD에서는 아키텍처가 별도로 있는것이 아니며, 위 아키텍처를 준수한다고
DDD의 목표에 도달하는것도 아니다. DDD를 실현하기 위해서는 위 아키텍처를
잘 이해하고 활용해야 할 필요는 있다.
해당 아키텍처에대한 설명은 그림과 링크로 대체합니다.
계층형 아키텍처
참고링크 : https://wikibook.co.kr/article/layered-architecture/
헥사고널 아키텍처
참고링크 : https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
클린 아키텍처
참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
API 서비스에 기본 아키텍처 도입하기
계층형 아키텍처를 선택하고 RestAPI에 DDD컨셉을 반영을 시도해보겠습니다.
왼쪽그림은 의존성이고 오른쪽은 의존에따른 호출방향입니다.
계층형 아키텍처를 이해했으면, 아키텍처와 구현부를 맵핑해보고 규칙을 만들어보자
- A : 인터페이스가 인프라에 바로접근한다란 의미가 아니고, 의존요소를 활용한다란 의존성을 나타낸 그림입니다. MVC의존 규칙에 벗어나지는 않지만 DDD규칙에 어긋납니다.
- B : 위에서 아래요소를 의존할수 있지만, 아래에서 위 요소를 의존(참조) 할수 없습니다. 도메인 객체는 애플리케이션의 객체 참조를 얻을수 없습니다. ( DI는 프레임워크별로 학습해야하는 영역입니다. )
- C : 어플리케이션도 도메인 요소중하나이며, 다른 서비스와 협업이 필요할시 n개의 서비스를 가질수 있습니다.
- D : 일반적으로 한단계 아래 의존요소를 활용하는것이 원칙입니다 예를들면 UserController가 Service를 건너 뛰고 인프라요소를 직접 조작하면 안됩니다. 도메인의 중요 규칙은 Service에 존재해야하기
때문입니다. 하지만 서비스의 트랜잭션 전체를 실패시키는 패턴이 있을경우 계층을 넘어서는 경우가 발생하기도 합니다.
- E : 해당 서비스와 관련있는 entity는 서비스에 의해서만 조작명령이 수행될수 있습니다.
- F : DataBase를 조작하는 행위는 인프라에 해당하며, 도메인영역과 완전하게 분리합니다. 이것은 레파지토리 패턴에서 잘 설명되어 있습니다. 이것은 ORM이던 아니던 상관없습니다.
Application LayOut
위 내용을 근거로 API의 어플리케이션 레이아웃을 정의해봅니다.
어플리케이션의 규모에따라 네임스페이스의 계층이 더 체계적이고다양해질수 있으며
계층형 아키텍처 베이스로 Application 네임스페이스를 우선은 심플하게 구성하였으며
도메인 핵심개념을 분리하는것이 주 목적이며 , 아직 DDD의 컨셉이 완전하게 반영된 구조가 아니며
재 조정될수 있습니다.
Controllers : API인터페이스 정의
- UserController
Services : 어플리케이션/도메인 계층
-User : User도메인을 응집화
-UserAppService
-UserService
Entity : 엔티티를 집합
-UserEntity
Repositories : 인프라계층중 레파지토리들
-UserRepository |
위 내용베이스로 DDD 학습을 위해 준비물
- 기본 닷넷 코어 API를 생성 ( +도커지원)
- 도커에 mysql을 탑재하여 로컬에 구동될수 있게 셋팅
- 레파지토리 패턴을 위해 ORM - Entity FrameWork활용