변종활동을 하기전에 아키텍처를 선택하고 활용해보자 최고 설계 다음으로 좋은 설계는 나쁜설계이다. 이말은 아무런 설계없이 구현부터 시작하는것에대한 문제를 이야기하는것이다 - ddd의 어느문구중 |
DDD에서는 아키텍처가 별도로 있는것이 아니며, 위 아키텍처를 준수한다고
DDD의 목표에 도달하는것도 아니다. DDD를 실현하기 위해서는 위 아키텍처를
잘 이해하고 활용해야 할 필요가 있다.
해당 아키텍처에대한 설명은 그림과 링크로 대체합니다.
참고링크 : https://wikibook.co.kr/article/layered-architecture/
특이사항 : 전형적인 CRUD API에 적합한 아키텍처입니다.
특이사항 : CQRS 영역까지 포함한 아키텍처입니다.
참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
특이사항 : SOA에서 소개되고 활용되는 아키텍처입니다.
DDD에서는 아키텍처에서 표현된 도메인 모델과 코드의 일치성을 중요하게 생각하며 더나아가 코드로 도메인 모델이 설명이 되어야한다고 이야기 합니다. 이것은 도메인 코드를 작성하는 개발자가 곧 설계자여야하며 설계자와 코더로 이분화 되었을때, 코드는 결코 설계를 반영하지 않을것이다란 경고를 합니다. |
계층형 아키텍처를 선택하고 RestAPI에 DDD컨셉을 반영을 시도해보겠습니다.
왼쪽그림은 의존성이고 오른쪽은 의존에따른 호출방향입니다.
계층형 아키텍처를 이해했으면, 아키텍처와 구현부를 맵핑해보고 규칙을 만들어보자
위 내용을 근거로 API의 어플리케이션 레이아웃을 정의해봅니다.
어플리케이션의 규모에따라 네임스페이스의 계층이 더 체계적이고다양해질수 있으며
계층형 아키텍처 베이스로 Application 네임스페이스를 우선은 심플하게 구성하였으며
도메인 핵심개념을 분리하는것이 주 목적이며 , 아직 DDD의 컨셉이 완전하게 반영된 구조가 아니며
재 조정될수 있습니다.
// 아직은 도메인 이벤트가 없는 버전 // CRUD를 위한 계층형구조를 먼저 완성한후, CQRS를 위한 헥사고널로 확장 예정입니다. Controllers : API인터페이스 정의 - UserController Services : 어플리케이션/도메인 계층 -User : User도메인을 응집화 -UserAppService -UserService Entity : 엔티티를 집합 -UserEntity Repositories : 인프라계층중 레파지토리들 -UserRepository |
다음아티컬에서는 위 기본 아키텍처를 베이스로 다음항목을 준비예정입니다.