비즈니스 개념을 담은 식별 기준이 된 DDD

인공지능 시대의 소프트웨어 공학

Aug 8. 2025

Transaction Script 패턴에 이어서 경험을 역사처럼 훑어보며 이야기를 전개하는 중에 DDD 빌딩 블록을 다시 보니 전에는 보이지 않던 요소가 보입니다.

DDD 빌딩 블록과 3 계층 아키텍처 패턴

사실 도식을 인용하고 전부터 보던 카탈로그임에도 새삼 정말 잘 정리했다고 감탄을 했습니다. 더불어 저자인 Eric Evans가 2003년에 출간한 책이 20 년이 넘도록 유효하다는 사실이 놀랍기도 했습니다. 그런데 가만히 보니 붉은색으로 칠한 영역은 앞서 <객체 식별의 어려움에서 기인한 패턴들>에서 다룬 3 계층 아키텍처 패턴에서 데이터 계층(Data tier)에 바탕을 둔 빌딩 블록이었습니다.

하지만, 위 그림은 오해의 소지가 있습니다. DDD는 모델 주도의 설계를 하는데, 이에 따르면 Layered Architecture에 따라 도메인 계층을 다른 층과 구분합니다. 그리하여 기존의 3 계층 아키텍처 패턴에 대응시키면 로직 계층 부분을 도메인 계층으로 구성하는 전략을 취한다고 할 수 있습니다. 그렇게 되면 빌딩 블록 전부가 로직 계층에 존재하게 되죠.

제가 앞서 데이터 계층과 연관된 요소를 붉은색으로 표기한 것은 기능적 종속성을 표현한 것입니다. 다시 말해, 위에서 녹색 테투리 칠한 빌딩 블록 중에서 도메인 이벤트와 서비스를 제외한 나머지는 영속성(Persistence) 문제와 관련이 있다는 말입니다. 그러나, 이를 다른 계층의 문제로 격리하자는 것이 DDD 접근의 특징입니다.

글을 마치며...

이런 각도에서 보니 DDD는 Transaction Script 패턴의 대안으로 어떻게 하면 비즈니스 계층이 비즈니스 개념을 담은 "모델"에 걸맞게 '식별(識別)할 수 있는 기준'이라는 생각이 들었습니다.

DDD 빌딩 블록에 Module이 있긴 하지만, DDD는 분명 모듈성 관점이 강력하지는 않다는 생각이 듭니다. 사실 DDD 책이 등장할 때만 해도 하나의 데이터베이스에 모든 데이트를 보관하는 일(요즘 표현으로 하면 모노리식 애플리케이션)이 상식적이었으니까요. 하지만, 모듈에서 상태 관리를 빼버리면 그 가치가 절반으로 줄어드는 게 아닌가 싶은 생각이 듭니다. 이에 대해서는 다음 글에서 다뤄 보기로 합니다.