사실 많은 사람들이 혼용해서 설명하는 클린 아키텍처와 도메인 주도 설계(DDD)는 소프트웨어 설계에 대해 접근하는 명확히 다른 관점이다.
DDD는 복잡한 비즈니스 도메인을 소프트웨어로 모델링하는 방법론으로, 2003년에 에릭 에반스라는 사람이 제안했다. 도메인 전문가와 개발자가 공통의 언어(Ubiquitous Language)를 사용하여 비즈니스 로직을 코드로 표현하는 방법에 집중한다. 엔티티(Entity), 값 객체(Value Object), 애그리게이트(Aggregate), 도메인 서비스, 리포지토리, 도메인 이벤트같은 개념이 여기서 제안됐다.
한편 클린 아키텍처는 의존성 규칙을 통해 관심사를 분리하는 아키텍처 패턴으로, 로버트 마틴이 제안했다. 소프트웨어가 풀고자 하는 문제(비즈니스 로직, 유즈 케이스(ref2))를 최대한 추상적으로 유지하여 기술의 변화로부터 보호하는 것을 목적으로 한다. 기술 세부사항 분리에 집중하므로, 헥사고날 아키텍처-양파 아키텍처의 계보를 잇는 계층화 아키텍처라고 볼 수 있다(ref1). DDD를 검색했을 때 양파 단면처럼 동심원 구조로 표현된 그림이 보인다면, DDD를 클린 아키텍처(계층화 아키텍처)의 개념을 결합하여 설명하고 있음을 인지하면 되고, 클린 아키텍처를 검색했을 때 ‘도메인’같은 단어가 보인다면, DDD의 개념을 담아 클린 아키텍처를 설명하고 있음을 인지하면 된다.
참고로, 클린 아키텍처에도 엔티티(Entity)라는 개념이 등장하지만, DDD에서 말하는 엔티티와는 의미하는 바가 다르다. 클린 아키텍처의 엔티티는 "핵심 비즈니스 규칙을 담은 객체"를 의미하고, DDD의 엔티티는 "식별자를 가진 도메인 객체"를 의미한다. 이러한 용어의 중첩이 혼란을 가중시킨다.
이처럼 DDD는 "무엇을" 만들 것인가에 집중하고 클린 아키텍처는 "어떻게" 구조화할 것인가에 집중한다. 그런데 왜 이들은 이렇게 자주 묶여 설명될까?
우선 두 접근법 모두 풀고자 하는 문제를 기술 세부사항으로부터 분리하려는 동일한 목표를 가지고 있다. DDD는 도메인 모델이 인프라스트럭처에 오염되지 않기를 원하고, 클린 아키텍처는 의존성 규칙을 통해 비즈니스 로직이 프레임워크나 데이터베이스에 의존하지 않기를 원한다. 이러한 철학적 일치가 두 개념을 자연스럽게 연결시킨다.
클린 아키텍처는 "계층을 어떻게 나눌 것인가"라는 구조적 가이드라인을 제공하지만, 각 계층에 "무엇을 넣을 것인가"에 대해서는 구체적이지 않다. 이때 클린 아키텍처의 가장 안쪽 원인 엔티티 계층을 DDD의 도메인 모델(엔티티, 값 객체, 도메인 서비스와 같은 개념으로 표현 가능)로 채울 수 있다. 반면 DDD는 풍부한 도메인 모델링 도구들을 제공하지만, 이를 전체 시스템 아키텍처에 어떻게 배치할지에 대한 명확한 지침은 부족하다. 따라서 두 접근법을 결합하여 사용하면 각각의 관심사에서 추상적으로 다루어지는 부분을 구체화할 수 있다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
1.
•
조금만 소스코드가 커지거나, 동시에 작업하는 프로젝트가 두세개만 되더라도 파일을 일관된 원칙으로 찾기 어려웠다. 프로젝트 단위의 스캐폴딩 일관성이 필요했다. 이 문제를 해결하기 좋은, 꽤나 널리 사용되는 패턴이 클린 아키텍처와 도메인 주도 설계임을 알게 되었다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
1.
ref : 생각에 참고한 자료입니다.