도메인 주도 설계 등장 배경

왜 DDD 를 해야 하는가?

클린 코드

나의 첫번째 회사에서는 자바를 이용하면서도 OOP 의 개념을 코드에 적용하지 않았고, 5000 줄이 넘는 메서드를 가진 컨트롤러 코드를 보았고, 존재 이유를 모르는 오류 검사 코드와 수많은 분기문이 있었다. 이 메서드는 새로운 요구 사항이 추가되거나 버그가 발생할 때마다 4~5줄씩 증가했다. 메서드를 고칠 때마다 코드도 분석해야 했지만, 기존 코드가 이렇게 동작하고 있다는 것을 기획자가 알고 있는지 매번 확인까지 해야 했다.

코드의 양은 많았지만, 기획자가 실제로 알고 있던 것과 다른 부분도 있었다. 기획자가 알고 있는 비즈니스 규칙은 자바뿐만 아니라 자바스크립트와 SQL에도 구현되어 있으며, 코드가 아닌 운영 정책으로 존재하기도 했다. (특히 어드민은 검증 로직이 없는 경우가 허다했다..)

이러한 코드 복잡성 문제를 해결하기 위한 다양한 고민과 노력이 담긴 다양한 방법론과 아키텍처가 존재하며, 클린 아키텍처를 가장 일반적으로 살펴본다. (로버트 C. 마틴의 클린 아키텍처)

클린 아키텍처는 로버트 C. 마틴이 제안한 좋은 소프트웨어 아키텍처의 보편적인 원칙으로 다음과 같은 특징을 가지고 있다. (독립성이 강조된다)

이름	설명
프레임워크 독립성	아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항 안으로 시스템을 욱여 넣도록 강제하지 않는다.
테스트 용이성	업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
UI 독립성	시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
데이터베이스 독립성	오라클이나 MS SQL 서버를 몽고DB, 빅테이블, 카우치DB 등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성	실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

도메인 주도 설계

자연스럽게 클린 아키텍처에 대해서 고민하다 보면, 복잡한 비즈니스 규칙을 다루는 엔티티와 유스케이스를 어떻게 설계하는가로 바뀌게 되고, DDD(도메인 주도 설계) 에 대한 고민으로 이어지게 된다. (에릭 에반스의 도메인 주도 설계)

왜 도메인 주고 설계인가?

기존의 개발

앞선 사례가 남의 일처럼 느껴지지 않을 것이다. 개발 과정과 관련된 예를 하나 더 들어보자.

1. 기획자와 심도 있는 논의를 거쳐 기획이 결정된다. (또는 기획자가 일방적으로 결정한다.)

2. 기획서를 보고 데이터베이스 테이블을 설계한다. (데이터 중심의 설계)

3. 데이터베이스 테이블을 기반으로 모델을 만든다.

4. getter와 setter 메서드가 모델에 추가된다.

5. 서비스가 매우 커진다.

또 하나 더 들어보자.

1. 기획자와 심도 있는 논의를 거쳐 기획이 결정된다. (또는 기획자가 일방적으로 결정한다.)

2. 기획서를 보니 데이터를 중복으로 관리하기보다는 기존 테이블에 새로운 컬럼 몇 개만 추가하면 될 것 같다.

3. 새로운 getter와 setter 메서드가 모델에 추가된다.

4. 서비스가 매우 커진다.

두 케이스 모두 결론적으로 서비스가 매우 커진다!

소프트웨어 존재 가치

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 관련 문제를 해결하는 능력에 있다. 아무리 기술적으로 정교하고 뛰어난 성능을 갖추더라도 당면한 문제를 해결하지 못하는 소프트웨어는 실패한 소프트웨어라고 할 수 있다. 얼마나 빠른지, 얼마나 많은 처리가 가능한지, 얼마나 많은 사람이 붙어 사용할 수 있는지는 나중 이야기이다.

소프트웨어를 만들려면 비즈니스를 이해하고, 관련 지식을 쌓고, 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)을 구별하는 것이 매우 중요하다.

아래 그래프에서 확인할 수 있듯이 우발적 복잡성은 초반에는 큰 영향력이 없지만, 시간이 지나가면 지나갈수록 본질적 복잡성보다 더 큰 영향을 끼치게 된다.

무엇이 문제인가?

고담 시내의 금융 지구 한가운데에는 얼마 전에 새로 지은 휘황찬란한 73층짜리 브론토사우루스 타워가 서 있다. 그런데 이 최고급 빌딩에 입주가 아직 끝나지도 않았는데 벌써 사무실 입주자들은 엘리베이터 서비스에 불만을 느끼고 있다. 실제로 몇몇 입주자는 엘리베이터 서비스를 하루빨리 개선하지 않는다면 그곳을 떠나겠다고 으름장을 놓고 있다.

출처: 제럴드 M. 와인버그, 대체 뭐가 문제야

'엘리베이터의 속도를 높인다', '업무 시간을 엇갈리게 배치하여 러시아워의 통행량을 분산시킨다', '빌딩 내로 들어오는 사람의 수를 제한한다'는 솔루션에 대해서만 설명한다. 심지어 엘리베이터 사용자 입장에서의 해결책이다. 건물주 입장에서 이야기하면 어떨까? 차라리 빌딩에 불을 질러서 태워버리고 보험금을 받는 것이 더 적절할 수 있다.

입장에 따라서 해결책이 달라진다는 것이다! (소프트웨어를 사용하는 사용자가 누구인지를 생각해보고, 그 입장에 맞는 설계를하는 것이 매우 중요하다)

도메인

우리가 소프트웨어로 해결하고자 하는 문제의 영역

도메인 모델

도메인 모델은 도메인에 대한 아이디어이자, 목적을 가진 의사소통 수단이다.

도메인 모델을 통해 도메인 관련자(개발자, 기획자, 디자이너, PM 등등 ..) 들은 동일한 모습으로 도메인을 이해하고 모델링 할 수 있다.

도메인 주도 설계

현실은 어떤가? 도메인 관련자들끼리 도메인 모델이 달라 문서화, 회의 시 많은 의사소통의 비용이 발생하기도 한다.

에릭 에반스의 동명의 책에서 유래한 DDD(Domain-Driven Design)는 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 다양한 원칙과 패턴을 제안한다. 그러나 결코 "설계를 하라, 그 다음에 구축하라"가 아니다.

DDD는 설계를 마친 후 개발하는 방식이 아니라, 도메인을 탐색하고 학습하면서 설계와 구현을 함께 발전시키는 접근 방식이다. 즉, "도메인을 이해하면서 점진적으로 개발하는 방식"이라고 볼 수 있다. (처음부터 완벽한 설계는 없다..!)

이를 기반으로 한 프로세스를 정리하면 다음과 같다.

단계	설명
1️⃣ 도메인 탐색 (Exploration)	- 비즈니스 전문가(도메인 전문가, PO)와 개발자가 함께 도메인을 이해 - 유비쿼터스 언어(Ubiquitous Language) 정의 - 핵심 도메인과 서브(하위) 도메인 식별
2️⃣ 모델링 및 설계 (Modeling & Design)	- 바운디드 컨텍스트(Bounded Context) 정의 - 애그리거트(Aggregate), 엔티티(Entity), 값 객체(Value Object) 식별 - 이벤트 스토밍(Event Storming) 등 사용
3️⃣ 작동 가능한 코드로 구현 (Incremental Implementation)	- 모델을 기반으로 코드 작성 (설계와 구현을 함께 발전시킴) - 리팩토링을 통해 점진적으로 개선
4️⃣ 검증 및 피드백 (Verification & Feedback)	- 도메인 전문가와 함께 검증, 피드백 반영 - 테스트 주도 개발(TDD) 및 이벤트 기반 테스트 활용
5️⃣ 반복적 개선 (Iterative Refinement)	- 점진적 리팩토링을 통해 우발적 복잡성 제거 - 유지보수성과 확장성을 고려하여 개선