사실 많은 사람들이 혼용해서 설명하는 클린 아키텍처와 도메인 주도 설계(DDD)는 소프트웨어 설계에 대해 접근하는 명확히 다른 관점이다.

DDD는 복잡한 비즈니스 도메인을 소프트웨어로 모델링하는 방법론으로, 2003년에 에릭 에반스라는 사람이 제안했다. 도메인 전문가와 개발자가 공통의 언어(Ubiquitous Language)를 사용하여 비즈니스 로직을 코드로 표현하는 방법에 집중한다. 엔티티(Entity), 값 객체(Value Object), 애그리게이트(Aggregate), 도메인 서비스, 리포지토리, 도메인 이벤트같은 개념이 여기서 제안됐다.

한편 클린 아키텍처는 의존성 규칙을 통해 관심사를 분리하는 아키텍처 패턴으로, 로버트 마틴이 제안했다. 소프트웨어가 풀고자 하는 문제(비즈니스 로직, 유즈 케이스(ref2))를 최대한 추상적으로 유지하여 기술의 변화로부터 보호하는 것을 목적으로 한다. 기술 세부사항 분리에 집중하므로, 헥사고날 아키텍처-양파 아키텍처의 계보를 잇는 계층화 아키텍처라고 볼 수 있다(ref1). DDD를 검색했을 때 양파 단면처럼 동심원 구조로 표현된 그림이 보인다면, DDD를 클린 아키텍처(계층화 아키텍처)의 개념을 결합하여 설명하고 있음을 인지하면 되고, 클린 아키텍처를 검색했을 때 ‘도메인’같은 단어가 보인다면, DDD의 개념을 담아 클린 아키텍처를 설명하고 있음을 인지하면 된다.

<aside> 💡 참고로, 클린 아키텍처에도 엔티티(Entity)라는 개념이 등장하지만, DDD에서 말하는 엔티티와는 의미하는 바가 다르다. 클린 아키텍처의 엔티티는 "핵심 비즈니스 규칙을 담은 객체"를 의미하고, DDD의 엔티티는 "식별자를 가진 도메인 객체"를 의미한다. 이러한 용어의 중첩이 혼란을 가중시킨다.

</aside>

이처럼 DDD는 "무엇을" 만들 것인가에 집중하고 클린 아키텍처는 "어떻게" 구조화할 것인가에 집중한다. 그런데 왜 이들은 이렇게 자주 묶여 설명될까?

우선 두 접근법 모두 풀고자 하는 문제를 기술 세부사항으로부터 분리하려는 동일한 목표를 가지고 있다. DDD는 도메인 모델이 인프라스트럭처에 오염되지 않기를 원하고, 클린 아키텍처는 의존성 규칙을 통해 비즈니스 로직이 프레임워크나 데이터베이스에 의존하지 않기를 원한다. 이러한 철학적 일치가 두 개념을 자연스럽게 연결시킨다.

클린 아키텍처는 "계층을 어떻게 나눌 것인가"라는 구조적 가이드라인을 제공하지만, 각 계층에 "무엇을 넣을 것인가"에 대해서는 구체적이지 않다. 이때 클린 아키텍처의 가장 안쪽 원인 엔티티 계층을 DDD의 도메인 모델(엔티티, 값 객체, 도메인 서비스와 같은 개념으로 표현 가능)로 채울 수 있다. 반면 DDD는 풍부한 도메인 모델링 도구들을 제공하지만, 이를 전체 시스템 아키텍처에 어떻게 배치할지에 대한 명확한 지침은 부족하다. 따라서 두 접근법을 결합하여 사용하면 각각의 관심사에서 추상적으로 다루어지는 부분을 구체화할 수 있다.

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.

  1. None

from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.

  1. 3_3_8.1. title: LLM 시대에 디자인패턴과 아키텍처에 익숙해진다는 것은 LLM과 공유하는 유비쿼터스 언어를 가지는 것이다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.

  1. 3_3_8.1.1.1. title: 인터페이스 계층은 외부에서 내부에 접근하는 방법, 내부에서 외부에 접근하는 방법을 관장한다. Repository와 Gateway는 접근 방법을 분리하는 개념이고, DTO와 Mapper은 데이터 변환을 분리하는 개념이다. ORM을 활용하면 DTO와 Mapper의 복잡성을 최소화할 수 있다.

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.

  1. None