(번역) DDD, Hexagonal, Onion, Clean, CQRS, … 이 모든 것을 어떻게 함께 사용할까요?
이 글은 소프트웨어 아키텍처 시리즈 글 중 소프트웨어 아키텍처 연대기의 일부입니다. 이 글에서는 제가 소프트웨어 아키텍처에 대해 배운 것과 생각하는 것, 그리고 그 지식을 어떻게 사용하는지에 대해 이야기합니다. 이 시리즈의 이전 글을 읽으셨다면 이 글의 내용을 더 잘 이해할 수 있을 것입니다.
저는 대학을 졸업한 후 고등학교 교사로 근무하다가 몇 년 전 교직을 그만두고 풀타임 소프트웨어 개발자가 되기로 결심했습니다.
그때부터 저는 항상 ‘잃어버린’ 시간을 되찾고 가능한 한 많은 것을, 가능한 한 빨리 배워야 한다고 생각했습니다. 그래서 저는 소프트웨어 디자인과 아키텍처에 특히 중점을 두고 실험하고, 읽고, 글을 쓰는 데에 약간 중독(?)되었습니다. 그래서 제가 이 글을 쓰는 이유는 제 배움에 도움이 되기 위해서입니다.
지난 글에서 저는 제가 배운 많은 개념과 원리에 대해 글을 썼고, 그것에 대해 어떻게 추론하는지에 대해서도 약간 언급했습니다. 하지만 저는 이런 내용들이 큰 퍼즐의 한 조각에 불과하다고 생각합니다.
오늘의 글에서는 이 모든 요소를 어떻게 결합하는지에 대해 설명합니다. 이름을 지어야 한다면 명시적 아키텍처라고 부르려고 합니다. 또한 이러한 개념은 모두 “실전 테스트를 모두 통과”했으며 매우 까다로운 플랫폼의 프로덕션 코드에 사용되고 있습니다. 전 세계 수천 개의 쇼핑몰이 있는 SaaS 전자상거래 플랫폼과 매월 2천만 개 이상의 메시지를 처리하는 메시지 버스를 통해 2개국에서 운영되는 오픈 마켓에서 사용되고 있습니다.
시스템의 기본 블록
먼저 EBI 아키텍처와 포트 & 어댑터 아키텍처를 떠올려보죠. 이 두 아키텍처는 애플리케이션 내부 코드와 외부 코드, 내부 코드와 외부 코드를 연결하는 데 사용되는 코드를 명시적으로 구분합니다.
또한 포트 & 어댑터 아키텍처는 시스템에서 세 가지 기본 코드 블록을 명시적으로 구분합니다.
- 사용자 인터페이스의 유형에 관계없이, 사용자 인터페이스를 실행할 수 있게 하는 요소
- 사용자 인터페이스에서 실제로 작업을 수행하는 데 사용되는 시스템 비즈니스 로직 또는 애플리케이션 코어
- 애플리케이션 코어를 데이터베이스, 검색 엔진 또는 서드파티 API와 같은 도구에 연결하는 인프라 코드
애플리케이션 코어는 우리가 정말 신경 써야 하는 중요한 부분입니다. 애플리케이션 코어는 애플리케이션이 해야 할 일을 할 수 있게 해주는 코드가 모여있습니다. 여러 사용자 인터페이스(프로그레시브 웹 앱, 모바일, CLI, API 등)를 사용할 수 있지만 실제로 작업을 수행하는 코드는 동일하며 애플리케이션 코어에 있으므로 어떤 UI가 이를 트리거하는지는 크게 중요하지 않습니다.
상상할 수 있듯이 일반적인 애플리케이션 흐름은 사용자 인터페이스의 코드에서 애플리케이션 코어를 거쳐 인프라 코드로, 다시 애플리케이션 코어로 돌아가 최종적으로 사용자 인터페이스에 응답을 전달하는 방식으로 진행됩니다.
도구
시스템에서 가장 중요한 코드인 애플리케이션 코어와는 별도로 데이터베이스 엔진, 검색 엔진, 웹 서버 또는 CLI 콘솔(마지막 두 가지도 전달 메커니즘이지만)같은 애플리케이션이 사용하는 도구가 있습니다.
CLI 콘솔을 데이터베이스 엔진과 같은 “버킷”에 넣는 것이 이상하게 느껴질 수도 있는 즉, 두 도구는 서로 다른 목적을 가지고 있지만 실제로는 애플리케이션에서 사용하는 도구입니다. 가장 큰 차이점은 CLI 콘솔과 웹 서버는 애플리케이션에 어떤 작업을 지시하는 데 사용되는 반면, 데이터베이스 엔진은 애플리케이션에 의해 어떤 작업을 지시받는다는 점 입니다. 이는 이러한 도구를 애플리케이션 코어와 연결하는 코드를 작성하는 방법에 큰 영향을 미치기 때문에 매우 중요한 구분입니다.
도구 및 전달 메커니즘을 애플리케이션 코어에 연결하기
도구를 애플리케이션 코어에 연결하는 코드 단위를 어댑터(포트 & 어댑터 아키텍처)라고 합니다. 어댑터는 비즈니스 로직이 특정 도구와 통신하거나 그 반대로 통신할 수 있도록 하는 코드를 효과적으로 구현하는 역할을 합니다.
애플리케이션에 작업을 지시하는 어댑터를 Primary 또는 Driving 어댑터라고 하고, 애플리케이션이 작업을 지시하는 어댑터를 Secondary 또는 Driven 어댑터라고 합니다.
포트
그러나 이러한 어댑터는 무작위로 생성되지 않습니다. 애플리케이션 코어에 대한 매우 구체적인 진입점인 포트에 맞게 만들어집니다. 포트는 도구가 애플리케이션 코어를 사용할 수 있는 방법 또는 애플리케이션 코어가 도구를 사용하는 방법에 대한 사양에 불과합니다. 대부분의 언어에서 이 사양인 포트는 가장 단순한 형태로 인터페이스가 되지만 실제로는 여러 개의 인터페이스와 DTO(Data Transfer Object)로 구성될 수 있습니다.
포트(인터페이스)는 비즈니스 로직 내부에 속하고 어댑터는 외부에 속한다는 점에 유의하는 것이 중요합니다. 이 패턴이 제대로 작동하려면 단순히 도구 API를 모방하는 것이 아니라 애플리케이션 코어의 요구사항에 맞게 포트를 만드는 것이 가장 중요합니다.
Primary 또는 Driving 어댑터
Primary 또는 Driver 어댑터는 포트를 감싸고 이를 사용하여 애플리케이션 코어에 수행할 작업을 지시합니다. 이들은 전달 메커니즘에서 오는 모든 것을 애플리케이션 코어의 메서드 호출로 변환합니다.
즉, Driving 어댑터는 컨트롤러 또는 콘솔 명령어로서, 생성자에 컨트롤러 또는 콘솔 명령어가 필요로 하는 인터페이스(Port)를 구현하는 클래스의 객체가 주입됩니다.
더 구체적인 예를 들면, 포트는 컨트롤러가 필요로 하는 서비스 인터페이스 또는 리포지토리 인터페이스일 수 있습니다. 그런 다음 서비스, 리포지토리 또는 쿼리의 구체적인 구현이 컨트롤러에 주입되어 사용됩니다.
또는 포트는 커맨드 버스 또는 쿼리 버스 인터페이스일 수 있습니다. 이 경우 커맨드 또는 쿼리 버스의 구체적인 구현이 컨트롤러에 주입되고, 컨트롤러는 커맨드 또는 쿼리를 생성하고 관련 Bus에 전달합니다.
Secondary 또는 Driven 어댑터
포트를 감싸는 Driver 어댑터와 달리 Driven 어댑터는 포트, 인터페이스를 구현한 다음 포트가 필요한(type-hinted) 애플리케이션 코어에 주입됩니다.
예를 들어, 데이터를 지속해야 하는 단순한 애플리케이션이 있다고 가정해 봅시다. 따라서 데이터 배열을 저장하는 메서드와 ID로 테이블의 행을 삭제하는 메서드가 포함된 요구 사항이 충족된 지속성 인터페이스를 만듭니다. 그 후 애플리케이션에서 데이터를 저장하거나 삭제해야 할 때마다 생성자에 정의한 지속성 인터페이스를 구현하는 객체가 필요합니다.
이제 해당 인터페이스를 구현할 MySQL 전용 어댑터를 만듭니다. 이 어댑터는 배열을 저장하고 테이블의 한 행을 삭제하는 메서드가 있으며, 지속성 인터페이스가 필요한 곳에 주입됩니다.
만약 어느 시점에 데이터베이스 공급자를 변경하기로 결정한 경우(예: PostgreSQL 또는 MongoDB), 지속성 인터페이스를 구현하고 PostgreSQL에 특정한 새 어댑터를 만들고 이전 어댑터 대신 새 어댑터를 주입하기만 하면 됩니다.
제어의 역전(Inversion of control)
이 패턴에서 주목해야 할 특징은 어댑터가 특정 도구와 특정 포트(인터페이스 구현)에 의존한다는 점입니다. 하지만 우리의 비즈니스 로직은 비즈니스 로직 요구에 맞게 설계된 포트(인터페이스)에만 의존하기 때문에 특정 어댑터나 도구에 의존하지 않습니다.
이는 종속성의 방향이 중앙을 향하고 있음을 의미하며, 아키텍처 수준에서 제어의 역전입니다.
다시 한 번 강조하지만, 포트는 단순히 도구 API를 모방하는 것이 아니라 애플리케이션 코어의 요구 사항에 맞게 만들어지는 것이 가장 중요합니다.
애플리케이션 코어 조직(Organisation)
어니언(Onion) 아키텍처는 DDD 계층을 가져와 포트 & 어댑터 아키텍처에 통합합니다. 이러한 계층은 포트 & 어댑터의 “육각형” 내부인 비즈니스 로직에 몇 가지 조직을 제공하기 위해 설계되었으며, 포트 & 어댑터와 마찬가지로 종속성 방향은 중앙을 향합니다.
애플리케이션 계층
유스 케이스(Use case)는 애플리케이션의 하나 또는 여러 사용자 인터페이스에 의해 애플리케이션 코어에서 트리거될 수 있는 프로세스입니다. 예를 들어, CMS에는 일반 사용자가 사용하는 실제 애플리케이션 UI, CMS 관리자를 위한 또 다른 독립적인 UI, 또 다른 CLI UI, 웹 API가 있을 수 있습니다. 이러한 UI(애플리케이션)는 하나의 UI에 특정되거나 여러 UI에서 재사용될 수 있는 유스케이스를 트리거할 수 있습니다.
유스 케이스는 DDD에서 제공하는 첫 번째 계층인 애플리케이션 계층에 정의되어 있으며, 어니언 아키텍처에서 사용됩니다.
이 계층은 일급 시민으로 애플리케이션 서비스(및 해당 인터페이스)를 포함하지만 ORM 인터페이스, 검색 엔진 인터페이스, 메시징 인터페이스 등을 포함하는 포트 & 어댑터 인터페이스(포트)도 포함합니다. 커맨드 버스 및/또는 쿼리 버스를 사용하는 경우 이 계층은 커맨드 및 쿼리에 대한 각 핸들러가 속하는 계층입니다.
애플리케이션 서비스 및/또는 커맨드 핸들러에는 유스 케이스, 즉 비즈니스 프로세스를 전개하는 로직이 포함되어 있습니다. 일반적으로 이들의 역할은 다음과 같습니다.
- 리포지토리를 사용하여 하나 또는 여러 개의 엔티티를 찾습니다.
- 해당 엔티티에 도메인 로직을 수행하도록 지시합니다.
- 그리고 리포지토리를 사용하여 엔티티를 다시 유지함으로써 데이터 변경 사항을 효과적으로 저장합니다.
커맨드 핸들러는 두 가지 방식으로 사용할 수 있습니다.
- 유스 케이스를 수행하기 위한 실제 로직을 포함할 수 있습니다.
- 아키텍처에서 단순한 연결 조각으로 사용될 수 있습니다. 커맨드를 수신하고 애플리케이션 서비스에 존재하는 로직을 단순히 트리거합니다.
어떤 접근 방식을 사용할지는 상황에 따라 다릅니다. 예를 들어,
- 이미 애플리케이션 서비스가 있고 커맨드 버스를 추가하고 있습니까?
- 커맨드 버스는 핸들러로 임의의 클래스/메서드를 지정할 수 있습니까? 아니면 기존 클래스나 인터페이스를 확장하거나 구현해야 합니까?
이 계층에는 유스 케이스의 일부 결과를 나타내는 애플리케이션 이벤트를 트리거 하는 것도 포함됩니다. 이러한 이벤트는 이메일 전송, 서드파티 API 알림, 푸시 알림 전송, 애플리케이션의 다른 구성 요소에 속하는 다른 유스 케이스 시작 등 유스 케이스의 부수 효과(side-effect) 로직을 트리거합니다.
도메인 계층
더 안쪽으로 들어가면 도메인 계층이 있습니다. 이 계층의 객체에는 데이터와 해당 데이터를 조작하는 로직이 포함되어 있습니다. 이는 도메인 자체에 특화되며 해당 로직을 트리거하는 비즈니스 프로세스와 독립적입니다. 이들은 독립적이며 애플리케이션 계층을 완전히 인식하지 못합니다.
□ 도메인 서비스
위에서 언급했듯이 애플리케이션 서비스의 역할은 다음과 같습니다.
- 리포지토리를 사용하여 하나 또는 여러 개의 엔티티를 찾습니다.
- 해당 엔티티에 도메인 로직을 수행하도록 지시합니다.
- 그리고 리포지토리를 사용하여 엔티티를 다시 유지함으로써 데이터 변경 사항을 효과적으로 저장합니다.
도메인 로직 중 일부는 여러 엔티티(같은 타입이든 다른 타입이든)와 관련되며, 이러한 로직을 엔티티 자체에 포함시키는 것이 적절하지 않다고 느낄 수도 있습니다. 왜냐하면 이러한 로직은 엔티티의 직접적인 책임이 아니라고 생각하기 때문입니다.
따라서 이럴 때 우리의 첫 번째 반응은 해당 로직을 엔티티 외부, 즉 애플리케이션 서비스에 배치하는 것일 수 있습니다. 그러나 이는 해당 도메인 로직이 다른 유스케이스에서 재사용될 수 없음을 의미합니다. 도메인 로직은 애플리케이션 레이어에 포함되지 않아야 합니다!
해결책은 일련의 엔티티를 수신하고 이에 대해 일부 비즈니스 로직을 수행하는 역할을 하는 도메인 서비스를 만드는 것입니다. 도메인 서비스는 도메인 계층에 속하므로 애플리케이션 서비스나 리포지토리와 같은 애플리케이션 계층의 클래스에 대해 아무것도 알지 못합니다. 반면에 다른 도메인 서비스는 물론 도메인 모델 객체를 사용할 수 있습니다.
□ 도메인 모델
가장 중심에는 도메인 모델이 있으며, 외부에 의존하지 않습니다. 도메인 모델은 도메인에서 무언가를 나타내는 비즈니스 객체를 포함합니다. 이러한 객체의 예시로 Entities, Value Objects, Enums 및 도메인 모델에서 사용되는 모든 객체가 있습니다.
도메인 모델은 도메인 이벤트가 “살아있는” 곳이기도 합니다. 이러한 이벤트는 특정 데이터 세트가 변경될 때 트리거되며 해당 변경 사항을 함께 전달합니다. 즉, 엔티티가 변경되면 도메인 이벤트가 트리거되고 변경된 속성의 새 값을 전달합니다. 이러한 이벤트는 예를 들어 이벤트 소싱에서 사용하기에 완벽합니다.
컴포넌트
지금까지는 레이어를 기준으로 코드를 분리했지만 이는 좀 더 세분화된 코드 분리입니다. 코드의 거친 수준의 분리도 그만큼 중요하며, 이는 로버트 C. 마틴의 screaming 아키텍처에서 표현된 아이디어에 따라 하위 도메인과 bounded context에 따라 코드를 분리하는 것입니다. 이는 종종 ‘레이어별 패키지’가 아닌 ‘기능별 패키지’ 또는 ‘컴포넌트별 패키지’라고 불리며, Simon Brown의 글 “컴포넌트별 패키지와 구조적으로 정렬된 테스트”에서 잘 설명되어 있습니다.
저는 ‘컴포넌트별 패키지’ 접근 방식을 지지하는 사람으로서, 컴포넌트별 패키지에 대한 사이먼 브라운의 다이어그램을 바탕으로 (뻔뻔하게도) 다음과 같이 수정했습니다.
이러한 코드 구분은 앞서 설명한 레이어와 교차하며 애플리케이션의 컴포넌트입니다. 컴포넌트의 예로는 인증, 권한 부여, 청구, 사용자, 검토 또는 계정 등이 있지만 항상 도메인과 관련이 있습니다. 권한 부여 및/또는 인증과 같은 bounded context는 어댑터를 생성하고 어떤 포트 뒤에 숨어 있는 외부 도구로 간주해야 합니다.
컴포넌트 디커플링
세분화된(fine-grained) 코드 단위(클래스, 인터페이스, 특성, 믹스인 등)와 마찬가지로 거칠게 쪼개진(coarsely-grained) 코드 단위(컴포넌트)도 낮은 결합과 높은 응집력의 이점을 누릴 수 있습니다.
클래스를 분리하기 위해 우리는 의존성 주입을 사용합니다. 이는 클래스 내부에서 인스턴스를 생성하는 대신 의존성을 클래스에 주입하는 방식입니다. 또한 의존성 역전을 통해 클래스가 구체적인 클래스가 아닌 추상화(인터페이스 및/또는 추상 클래스)에 의존하도록 만듭니다. 이는 의존하는 클래스가 사용할 구체적인 클래스에 대한 지식이 없음을 의미하며, 그것이 의존하는 클래스의 완전한 이름을 참조하지 않습니다.
마찬가지로, 완전히 분리된 컴포넌트를 가지고 있다는 것은 한 컴포넌트가 다른 컴포넌트에 대한 직접적인 지식이 없음을 의미합니다. 즉, 다른 컴포넌트에서의 세밀한 코드 단위에 대한 참조조차 없습니다. 이는 인터페이스 조차도 없음을 의미합니다! 이것은 의존성 주입과 의존성 역전만으로는 컴포넌트를 분리하는데 충분하지 않음을 의미하며, 우리는 어떤 종류의 아키텍처 구조가 필요할 것입니다. 우리는 이벤트, 공유 커널, 최종 일관성, 심지어는 디스커버리 서비스가 필요할 수도 있습니다!
□ 다른 컴포넌트의 로직 트리거하기
컴포넌트 중 하나(컴포넌트 B)가 다른 컴포넌트(컴포넌트 A)에서 무언가가 발생할 때마다 어떤 일을 수행해야 한다면, 단순히 컴포넌트 A에서 컴포넌트 B의 클래스/메서드로 직접 호출을 할 수 없습니다. 왜냐하면 그렇게 되면 A는 B에 결합되기 때문입니다.
그러나 컴포넌트 A가 이벤트 디스패처를 사용해 애플리케이션 이벤트를 발송하게 할 수 있습니다. 이 이벤트는 컴포넌트 B를 포함한 모든 이벤트를 수신하는 컴포넌트에 전달되며, B의 이벤트 리스너는 원하는 동작을 트리거할 것입니다. 이는 컴포넌트 A가 이벤트 디스패처에 의존하게 되지만, B와는 분리될 것임을 의미합니다.
그럼에도 불구하고 만약 이벤트 자체가 A에서 “생성”된다면 이는 B가 A의 존재를 알고 있음을 의미하며, B는 A에 종속됩니다. 이런 종속성을 제거하기 위해, 우리는 모든 컴포넌트들 사이에서 공유될 애플리케이션 핵심 기능의 집합을 가진 라이브러리를 만들 수 있습니다. 이것을 공유 커널(Shared Kernel)이라고 합니다. 이는 컴포넌트들이 공유 커널에 의존하게 되지만 서로는 분리될 것임을 의미합니다. 공유 커널은 애플리케이션 및 도메인 이벤트와 같은 기능을 포함하며, 또한 사양(Specification) 객체와 공유하는 것이 합리적인 다른 것들을 포함할 수 있습니다. 단, 공유 커널에 대한 모든 변경이 애플리케이션의 모든 컴포넌트에 영향을 미칠 수 있으므로 최소한으로 유지해야 합니다. 또한, 우리가 다양한 시스템을 가지고 있다면, 예를 들어 다른 언어로 작성된 마이크로서비스 생태계를 가지고 있다면, 공유 커널은 언어에 구애받지 않아야 하므로 모든 컴포넌트에서 이해할 수 있어야 합니다. 예를 들어, 공유 커널이 이벤트 클래스를 포함하는 대신에, 이것은 모든 컴포넌트/마이크로서비스가 해석하고 자신의 구체적인 구현을 자동 생성할 수 있도록 JSON과 같은 중립적인 언어로 이벤트 설명(예시로, 이름, 속성, 아마도 메소드들, 비록 이것들이 사양 객체에서 더 유용할 것이지만)을 포함할 것입니다. 이에 대한 자세한 내용은 제 후속 글인 ‘More than concentric layers’에서 더 읽어보실 수 있습니다.
□ 다른 컴포넌트에서 데이터 가져오기
제가 보기에 컴포넌트는 ‘소유’하지 않은 데이터를 변경할 수 없지만, 데이터를 쿼리하고 사용하는 것은 괜찮습니다.
컴포넌트 간에 공유되는 데이터 저장소
컴포넌트가 다른 컴포넌트에 속한 데이터를 사용해야 하는 경우, 예를 들어 빌링 컴포넌트가 계정 컴포넌트에 속한 고객 이름을 사용해야 하는 경우, 빌링 컴포넌트는 해당 데이터를 데이터 저장소에서 쿼리할 쿼리 객체를 포함하게 됩니다. 이는 단순히 빌링 컴포넌트가 어떤 데이터셋이든 알 수 있지만, 쿼리를 통해 “소유”하지 않은 데이터를 읽기 전용으로 사용해야 함을 의미합니다.
컴포넌트별로 분리된 데이터 저장소
이 경우에도 같은 패턴이 적용되지만, 데이터 저장소 수준에서 복잡성이 더해집니다. 각각의 데이터 저장소를 가진 컴포넌트는 다음을 포함합니다.
- 그것이 소유하고 유일하게 변경할 수 있는 데이터 집합으로, 이는 단일 진실 공급원이 됩니다.
- 다른 컴포넌트의 데이터의 복사본인 데이터 집합입니다. 이는 컴포넌트 기능에 필요하지만 스스로 변경할 수 없으며, 소유 컴포넌트에서 변경될 때마다 업데이트해야 합니다.
각 컴포넌트는 필요할 때 사용할 수 있도록 다른 컴포넌트로부터 필요한 데이터의 로컬 복사본을 생성합니다. 데이터가 그것을 소유한 컴포넌트에서 변경되면, 그 소유 컴포넌트는 데이터 변경을 담은 도메인 이벤트를 트리거할 것입니다. 해당 데이터의 복사본을 가진 컴포넌트들은 그 도메인 이벤트를 수신하고 그에 따라 자신의 로컬 복사본을 업데이트할 것입니다.
제어의 흐름
위에서 언급했듯이, 제어 흐름은 당연히 사용자로부터 애플리케이션 코어로, 인프라 도구로 넘어가서 다시 애플리케이션 코어로 돌아가고 마지막으로 다시 사용자에게 돌아갑니다. 그러나 정확히 클래스들은 어떻게 함께 맞물리는 건가요? 어떤 것들이 어떤 것들에 의존하는 건가요? 어떻게 그들을 구성해야 할까요?
엉클밥의 클린 아키텍처에 대한 글에 따라, 저는 UML과 유사한 다이어그램을 사용하여 제어 흐름을 설명하려고 합니다…
커맨드 / 쿼리 버스를 사용하지 않는다면
커맨드 버스를 사용하지 않는 경우, 컨트롤러는 애플리케이션 서비스 또는 쿼리 객체에 종속됩니다.
[수정 — 2017–11–18] 쿼리에서 데이터를 반환하는 데 사용하는 DTO를 완전히 놓쳐 지금 추가했습니다. 저를 위해 지적해 주신 MorphineAdministered에게 감사드립니다.
위의 다이어그램에서는 애플리케이션 서비스를 위한 인터페이스를 사용하고 있습니다. 비록 애플리케이션 서비스가 우리 애플리케이션 코드의 일부이며 다른 구현으로 교체하고 싶지 않을 수 있지만, 우리는 이를 완전히 리팩토링할 수 있습니다.
쿼리 객체는 사용자에게 보여줄 원시 데이터를 단순히 반환하는 최적화된 쿼리를 포함할 것입니다. 그 데이터는 DTO에 반환되어 ViewModel에 주입됩니다. 이 ViewModel은 일부 뷰 로직을 가질 수 있으며, 뷰를 채우는 데 사용됩니다.
한편으로, 애플리케이션 서비스는 유스 케이스 로직, 즉 시스템에서 무언가를 하고자 할 때 트리거할 로직을 포함할 것입니다. 이는 단순히 어떤 데이터를 보는 것과는 대조적입니다. 애플리케이션 서비스는 트리거해야 하는 로직을 포함한 엔티티(들)을 반환할 리포지토리에 의존합니다. 또한, 여러 엔티티에서 도메인 프로세스를 조정하기 위해 도메인 서비스에 의존할 수도 있지만, 그런 경우는 거의 없습니다.
유스 케이스를 펼친 후, 애플리케이션 서비스는 해당 유스 케이스가 발생했다는 것을 전체 시스템에 알리고자 할 수 있습니다. 이 경우, 이벤트를 트리거하기 위해 이벤트 디스패처에도 의존하게 됩니다.
우리가 지속성(persistence) 엔진과 리포지토리 모두에 인터페이스를 위치시키는 것이 흥미롭다는 점을 주목하는 것이 중요합니다. 비록 이것이 중복처럼 보일 수 있지만, 그들은 다른 목적을 가지고 있습니다.
- 지속성 인터페이스는 ORM 위의 추상화 계층으로, 애플리케이션 코어에 변경 없이 사용 중인 ORM을 교체할 수 있습니다.
- 리포지토리 인터페이스는 지속성 엔진 자체에 대한 추상화입니다. 가령, 우리가 MySQL에서 MongoDB로 전환하고 싶다고 가정합시다. 지속성 인터페이스는 동일할 수 있고, 우리가 같은 ORM을 계속 사용하고 싶다면, 지속성 어댑터조차도 동일하게 유지될 수 있습니다. 그러나, 쿼리 언어는 완전히 다르므로, 우리는 같은 지속성 메커니즘을 사용하지만 SQL 대신 MongoDB 쿼리 언어를 사용하여 쿼리를 구성하는 동일한 리포지토리 인터페이스를 구현하는 새로운 리포지토리를 생성할 수 있습니다.
커맨드 / 쿼리 버스를 사용한다면
우리의 애플리케이션이 커맨드 / 쿼리 버스를 사용하는 경우, 다이어그램은 대체로 동일하게 유지됩니다. 다만, 컨트롤러가 버스와 커맨드 또는 쿼리에 의존한다는 점이 예외입니다. 컨트롤러는 커맨드 또는 쿼리를 인스턴스화하고, 이를 버스에 전달하며, 버스는 적절한 핸들러를 찾아 커맨드를 받고 처리합니다.
아래의 다이어그램에서, 커맨드 핸들러는 그 다음에 애플리케이션 서비스를 사용합니다. 그러나, 이는 항상 필요한 것은 아닙니다. 실제로 대부분의 경우 핸들러는 유스케이스의 모든 로직을 포함합니다. 우리는 다른 핸들러에서 동일한 로직을 재사용해야 하는 경우에만 핸들러에서 로직을 분리된 애플리케이션 서비스로 추출해야 합니다.
[수정 — 2017–11–18] 쿼리에서 데이터를 반환하는 데 사용하는 DTO를 완전히 놓쳐서 지금 추가했습니다. 이를 지적해 주신 MorphineAdministered에게 감사드립니다.
여기서 당신은 버스와 커맨드, 쿼리 또는 핸들러 사이에 의존성이 없음을 알아챘을 수도 있습니다. 이는 그들이 실제로는 서로 인식하지 않아야 하며, 이를 통해 좋은 분리를 제공해야 하기 때문입니다. 버스가 어떤 핸들러가 어떤 커맨드 또는 쿼리를 처리해야 하는지 알게 되는 방식은 단순한 구성을 통해 설정되어야 합니다.
보시다시피, 두 경우 모두 애플리케이션 코어의 경계를 가로지르는 화살표, 즉 의존성들은 모두 안쪽을 가리킵니다. 이전에 설명했듯이, 이는 포트 & 어댑터 아키텍처, 어니언 아키텍처 및 클린 아키텍처의 기본 규칙입니다.
결론
항상 그렇듯이 목표는 변경이 쉽고, 빠르며, 안전하게 이루어질 수 있도록 코드베이스를 느슨하게 결합하고 높은 응집력을 가지도록 하는 것입니다.
“계획은 쓸모가 없지만, 계획하는 것은 모든 것이다.”
- 아이젠하워
이 인포그래픽은 개념도(concept map)입니다. 이러한 모든 개념을 알고 이해함으로써, 우리는 건강한 아키텍처, 건강한 애플리케이션을 위해 설계할 수 있습니다.
그러나,
“지도는 영토가 아니다.”
- 알프레드 코르지브스키
이것은 단지 지침일 뿐입니다! 애플리케이션은 영역이고, 현실이며, 우리가 지식을 적용해야 하는 구체적인 유스 케이스입니다. 그것이 실제 아키텍처가 어떻게 보일지를 결정할 것입니다!
우리는 이러한 패턴들을 모두 이해해야 하지만, 또한 항상 우리의 애플리케이션이 정확히 무엇을 필요로 하는지, 분리와 응집력을 위해 어디까지 나아가야 하는지를 생각하고 이해해야 합니다. 이 결정은 프로젝트의 기능적 요구사항부터 시작하여, 애플리케이션을 구축하는 데 필요한 시간, 애플리케이션의 수명, 개발 팀의 경험 등과 같은 요소를 포함할 수 있습니다.
이게 바로 제가 모든 것을 이해하는 방법입니다. 또한, 이것이 제 머리 속에서 합리화하는 방법입니다.
저는 이러한 아이디어들을 후속 게시물인 ‘More than concentric layers’에서 좀 더 확장했습니다.
그러나, 우리는 이 모든 것을 코드베이스에서 어떻게 명확하게 만들 수 있을까요? 그것은 제가 앞으로 작성할 다음 글에서 ‘코드에서 아키텍처와 도메인을 어떻게 반영할 것인가.’라는 주제로 이야기해보려 합니다.
마지막으로, 제 동료인 Francesco Mastrogiacomo에게 감사드립니다. 그는 나의 인포그래픽을 멋지게 만드는 데 도움을 주었습니다. 🙂
