변종활동을 하기전에 아키텍처를 선택하고 활용해보자

최고 설계 다음으로 좋은 설계는 나쁜설계이다.

이말은 아무런 설계없이 구현부터 시작하는것에대한 문제를 이야기하는것이다 - ddd의 어느문구중

기존 아키텍처 이해

DDD에서는 아키텍처가 별도로 있는것이 아니며, 위 아키텍처를 준수한다고

DDD의 목표에 도달하는것도 아니다. DDD를 실현하기 위해서는 위 아키텍처를

잘 이해하고 활용해야 할 필요가 있다.


해당 아키텍처에대한 설명은 그림과 링크로 대체합니다.

계층형 아키텍처

참고링크 : https://wikibook.co.kr/article/layered-architecture/

특이사항 : 전형적인 CRUD API에 적합한 아키텍처입니다.


헥사고널 아키텍처

참고링크 : https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

특이사항 : CQRS 영역까지 포함한 아키텍처입니다.

클린 아키텍처

참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html

특이사항 : SOA에서 소개되고 활용되는 아키텍처입니다.


DDD에서는 아키텍처에서 표현된 도메인 모델과 코드의 일치성을 중요하게 생각하며

더나아가 코드로 도메인 모델이 설명이 되어야한다고 이야기 합니다.

이것은 도메인 코드를 작성하는 개발자가 곧 설계자여야하며 

설계자와 코더로 이분화 되었을때, 코드는 결코 설계를 반영하지 않을것이다란 경고를 합니다.


API 서비스에 기본 아키텍처 도입하기

계층형 아키텍처를 선택하고 RestAPI에 DDD컨셉을 반영을 시도해보겠습니다.

왼쪽그림은 의존성이고 오른쪽은 의존에따른 호출방향입니다. 

계층형 아키텍처를 이해했으면, 아키텍처와 구현부를 맵핑해보고 규칙을 만들어보자


Application LayOut

위 내용을 근거로 API의 어플리케이션 레이아웃을 정의해봅니다.

어플리케이션의 규모에따라 네임스페이스의 계층이 더  체계적이고다양해질수 있으며

계층형 아키텍처 베이스로 Application 네임스페이스를 우선은 심플하게 구성하였으며

도메인 핵심개념을 분리하는것이 주 목적이며 , 아직 DDD의 컨셉이 완전하게 반영된 구조가 아니며

재 조정될수 있습니다.

// 아직은 도메인 이벤트가 없는 버전
// CRUD를 위한 계층형구조를 먼저 완성한후, 헥사고널로 리팩토링 예정입니다.
Controllers : API인터페이스 정의
 - UserController

Services : 어플리케이션/도메인 계층
 -User : User도메인을 응집화
   -UserAppService
   -UserService
Entity : 엔티티를 집합
  -UserEntity
Repositories : 인프라계층중 레파지토리들
 -UserRepository


다음아티컬에서는 위 기본 아키텍처를 베이스로 다음항목을 준비예정입니다.