도메인 주도 설계(Domain Driven Design, DDD)를 도입하는 회사나 DDD 경험 있는 개발자를 구하는 모집 공고가 흔하다.
커뮤니티 게시판에도 DDD 스터디 모집글이 보이고, 아는 지인들도 DDD 스터디 진행하거나 찾고 있다.
DDD가 무엇이고, 많은 회사와 개발자들이 매달리고 있을까?
우선 도메인이 등장한 배경부터 알아보자.
왜 도메인 주도 설계인가?
레거시는 이해할 수 없는 코드가 덕지덕지 있는 것을 경험해봤을 거다. 존재 이유를 모르는 코드 수많은 분기문이 있다.
이러한 형태는 새로운 요구 사항이 추가되거나 버그가 발생했을 때 해당 메서드에 코드가 여러줄이 증가하는 걸 볼 수 있다.
또한, 비즈니스 규칙은 자바뿐만 아니라 자바스크립트, SQL에도 구현되어 있으며, 코드가 아닌 운영 정책으로 존재하기도 한다.
레거시는 다음과 같은 개발 방식을 가진다.
1. 기획자와 심도있는 논의를 거쳐 기획이 결정된다. (혹은 기획자가 일방적인 결정을 한다.)
2. 기획서를 기준으로 데이터베이스 테이블을 설계한다. (ERD)
3. 데이터베이스 테이블을 기반으로 모델을 만든다.
4. getter & setter 메서드를 모델에 추가한다.
5. 시간에 따라 서비스가 매우 커진다.
이러한 개발방식은 새로운 요구사항이 생겨도 기존 테이블에 컬럼을 몇 개 추가하기 때문에 기존 모델에도 똑같이 getter & setter가 추가되어 서비스가 비대해진다.
어떻게 해야 레거시 같은 생태에서 벗어날 수 있을까?
결론은 '비즈니스 규칙을 한곳에 모으기'였다. 이런 고민에 대해 찾아보니 다양한 아키텍처와 패턴이 존재했고 그중에서 대표적으로 로버트 C. 마틴이 제안한 좋은 소프트웨어 아키텍처의 보편적인 원칙으로 클린 아키텍처 가 있었다.
클린 아키텍처의 특징
| 프레임워크 독립성 | 아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항 안으로 시스템을 욱여 넣도록 강제하지 않는다. | ||||
| 테스트 용이성 | 업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다. | ||||
| UI 독립성 | 시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다. | ||||
| 데이터베이스 독립성 | 오라클이나 MS SQL 서버를 몽고DB, 빅테이블, 카우치DB 등으로 교체할 수 있다. 비즈니스 규칙은 데이터베이스에 결합되지 않는다. | ||||
| 모든 외부 에이전시에 대한 독립성 | 실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다. | ||||
소프트웨어의 존재 가치
소프트웨어는 사용자의 문제를 해결하는 능력이 있다. 기술적 & 성능이 뛰어나도 문제를 해결하지 못하면 실패한 소프트웨어라 할 수 있다.
흔히 얼마나 빠른지, 얼마나 많은 처리가 되는지, 얼마나 많은 사람이 사용할 수 있는지는 나중 이야기다.
소프트웨어를 만들려면 비즈니스를 이해하고 관련 지식을 쌓고, 본질적 복잡성과 우발적 복잡성을 구별하는 것이 매우 중요하다.
도메인(Domain)
그렇다면 흔히 접하는 용어인 도메인이란 무엇일까?
도메인이란 '소프트웨어로 해결하고자 하는 문제 영역'을 의미한다. 일반적으로 비즈니스 성격을 띠는 경우가 많다.
사용자의 요구사항을 생각해보자. 이 요구사항으로 사용자의 활동과 관심사를 파악하고 소프트웨어를 통해 무엇을 하고 싶어 하는지 알 수 있다.
예) 쇼핑몰이라면 사용자의 요구사항을 이해하기 위해 전자상거래 지식이 필요하다.
이쯤이면 "어? 이거 매일 했던거잖아?" 라는 말이 나올 것이다.
맞다. 개발자라면 매일해오던 것을 도메인이란 용어로 표현한 거다.
소프트웨어는 살마의 욕망과 욕구를 해결하려고 만든 창조물입니다. 사람들의 욕망과 욕구가 개발자에게 전달됐을 때 우리는 그것을 도메인이라고 부릅니다. - 조영호
도메인 모델(Domain Model)
패션 모델, 모델 하우스, 프라모델 등 일상생활에서 모델이란 단어를 많이 접할 수 있다.
모델은 현실 세계에 존재하는 것을 가공하고 편집하여 우리에게 정보를 제공해주는 역할을 한다.
예) 패션 모델 - 패션에 대한 정보를 제공한다. / 모델 하우스 - 집에 대한 정보를 제공한다.
도메인 모델은 도메인을 개념적으로 표현한 것이며, 아이디어 & 목적을 전달하기 위한 의사소통 수단이다.
도메인 모델을 표현하는 다양한 방식(다이어그램, 그림 등)이 존재하며 회의, 기획, 디자인, 개발에 사용이 된다.
이를 통해 여러 이해관계자가 동일한 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.
하지만 현실은 여러 이해관계자가 서로 다른 생각을 가진 경우가 많다.
하나의 도메인에 대해서 사용자의 도메인 모델과 개발자의 도메인 모델이 같을까?
사용자는 비즈니스 언어로 생각할 테고 개발자는 기술 언어로 생각한다. 도메인 모델은 처음부터 일치하지 않는다.
서로 의사소통 방법에서 차이가 나고, 괴리감이 발생해서 잘못된 소프트웨어를 만드는 원인이 된다.
이런 괴리감을 해소하기 위한 방법 중 하나가 도메인 주도 설계다.
도메인 주도 설계 (Domain Driven Design)
에릭 에반스에 의해 유래된 도메인 주도 설계는 도메인 모델의 적용 범위를 구현으로 확장하여 괴리감을 없앤다.
참고할 것은 도메인 주도 '설계'란 용어 때문에 설계부터 해야 하는 건 아니다.
미숙한 설계 상태라도 구현을 하면서 설계를 잡아가도 된다. 설계와 구현을 동시에 진행할 수도 있다.
도메인 주도 설계에는 중요한 요소 3개가 있으며, 세부 요소를 포함하고 있다.
아래의 그림은 DDD를 구성하는 전체적인 요소를 표현한다.
차근차근 DDD를 알아보는 시간을 가져보자.
* 잘못된 내용이 있으면 댓글 부탁드립니다.
참고자료
'개발 & 방법론 > DDD' 카테고리의 다른 글
| 이벤트 스토밍(Event Storming) (0) | 2022.11.04 |
|---|---|
| 바운디드 컨텍스트(BOUNDED CONTEXT) (0) | 2021.12.16 |
| 유비쿼터스 언어(UBIQUITOUS LANGUAGE) (0) | 2021.12.15 |
| 테스트를 통한 코드 보호 (0) | 2021.10.15 |
| 레거시 코드, 빈약한 도메인 모델(Anemic Domain Model) (0) | 2021.10.06 |