변종활동을 하기전에 아키텍처를 선택하고 활용해보자
최고 설계 다음으로 좋은 설계는 나쁜설계이다.
이말은 아무런 설계없이 구현부터 시작하는것에대한 문제를 이야기하는것이다 - ddd의 어느문구중
기존 아키텍처 이해
- 계층형 아키텍처
- 헥사고날 아키텍처
- 클린 아키텍처
DDD에서는 아키텍처가 별도로 있는것이 아니며, 위 아키텍처를 준수한다고
DDD의 목표에 도달하는것도 아니다. DDD를 실현하기 위해서는 위 아키텍처를
잘 이해하고 활용해야 할 필요가 있다.
해당 아키텍처에대한 설명은 그림과 링크로 대체합니다.
계층형 아키텍처
참고링크 : https://wikibook.co.kr/article/layered-architecture/
특이사항 : 계층을 잘 나눠 도메인을 분리하자~
클린 아키텍처
참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
특이사항 : 같은 이야기이지만, SOA에서 활용이 주로 된듯
헥사고널 아키텍처
특이사항 : 도메인 이벤트를 활용하는 CQRS 영역까지 포함한 아키텍처입니다. 위에서 설명한 아키텍처를 계승하고 양념이 뿌려진듯
결국 아키텍처에서 공통으로 이야기하는 것은 관심사의 분리이며 각 아키텍처마다
동일하지만 분리하는 방식에 사용되는 용어가 약간 다르거나, 의존성을 구성하는 방법 접근방향등에
약간식의 차이가 있는것으로 보입니다.
DDD에서는 아키텍처에서 표현된 도메인 모델과 코드의 일치성을 중요하게 생각하며
더나아가 코드로 도메인 모델이 설명이 되어야한다고 이야기 합니다.
이것은 도메인 코드를 작성하는 개발자가 곧 설계자여야하며
설계자와 코더로 이분화 되었을때, 코드는 결코 설계를 반영하지 않을것이다란 경고를 합니다.
API 서비스에 기본 아키텍처 도입하기
계층형 아키텍처를 선택하고 RestAPI에 DDD컨셉을 반영을 시도해보겠습니다.
왼쪽그림은 의존성이고 오른쪽은 의존에따른 호출방향입니다.
계층형 아키텍처를 이해했으면, 아키텍처와 구현부를 맵핑해보고 규칙을 만들어보자
- A : 인터페이스가 인프라에 바로접근한다란 의미가 아니고, 의존요소를 활용한다란 의존성을 나타낸 그림입니다. MVC의존 규칙에 벗어나지는 않지만 DDD규칙에 어긋납니다.
- B : 위에서 아래요소를 의존할수 있지만, 아래에서 위 요소를 의존(참조) 할수 없습니다. 도메인 객체는 애플리케이션의 객체 참조를 얻을수 없습니다. ( DI는 프레임워크별로 학습해야하는 영역입니다. )
- C : 어플리케이션도 도메인 요소중하나이며, 다른 서비스와 협업이 필요할시 n개의 서비스를 가질수 있습니다. 어플리케이션은 여러서비스를 다루는 집합서비스로 이해하면 될것같습니다.
- D : 일반적으로 한단계 아래 의존요소를 활용하는것이 원칙입니다 예를들면 UserController가 Service를 건너 뛰고 인프라요소를 직접 조작하면 안됩니다. 도메인의 중요 규칙은 Service에 존재해야하기
때문입니다. 하지만 서비스의 트랜잭션 전체를 실패시키는 패턴이 있을경우 계층을 넘어서는 경우가 발생하기도 합니다. - E : 해당 서비스와 관련있는 entity는 서비스에 의해서만 조작명령이 수행될수 있습니다.
- F : DataBase를 조작하는 행위는 인프라에 해당하며, 도메인영역과 완전하게 분리합니다. 이것은 레파지토리 패턴에서 잘 설명되어 있습니다. 이것은 ORM이던 아니던 상관없습니다.
Application LayOut
구현해야할 도메인의 규모와 종류는 다를수 있으면 그에 따른, 적합한 아키텍처를 선택할수 있습니다.
여기서는 선택한 아키텍처와, 어플리케이션의 구현구조를 일치화하는것입니다.
이 아티컬에서 구현시도 예정인 Application Layout