DDD 이야기 part1
11 May 2017
by Jihoon
Domain Driven Design
우리는 프로그래밍을 통해 무엇을 이루려고 하는가?
현실의 본질(domain, 이하 domain 으로 통일)이 가지고 있는 문제나 요구사항을(needs) 해결하기 위해 소프트웨어를 설계한다. domain의 복잡성이 증가할 수록 소프트웨어의 복잡성또한 증가하게 된다. domain을 제대로 이해하고 설계를 해야 좋은 소프트웨어가 만들어질 가능 성이 높아진다.
그럼 domain을 어떻게 소프트웨어로 바꾸는가
본질을 잘 추상화 해서 모델을 만들고 만들어진 모델을 바탕으로 소프트웨어를 만든다.
모델
domain을 분석해서 모델을 만드는 일은 사실 늘 해오던 일이다. 다만 여기서 주의해야 할 점은 분석을 통해 얻어진 ‘분석 모델’과 실제 구현에 쓰일 ‘설계 모델’이 달라지면 안된다는 점이다. ‘분석 모델’과 ‘설계 모델’이 나뉘게 되면 domain에 요구사항이 늘어나거나, 변경이 생기거나, 시간의 경과로 인해 두 모델간의 결합성이 약해지게 된다는 것이다. 모델은 domain을 표현하기 위한 방법이지 구현을 편하게 하는 방법이 아니라는 점이다. 당장 구현이 복잡해 보일지라도 장기적으로 봤을 때 모델 속에 내재된 domain을 잃지 않는 것이 소프트웨어의 생명을 유지시켜줄 것이다.
‘잘’ 추상화 하는 방법
어떻게 하면 domain 을 ‘잘’ 추상화 할 수 있을까? DDD 에서는 분석 및 설계시에 domain을 제대로 알고 있는 전문가가 참여하고, 프로젝트 구성원 모두가 모델링 작업에 참여하기를 권장합니다.
도메인 전문가와 구성원들의 공통된 지식을 가지고 공통된 언어로 군더더기 없는 공통의 모델을 상상하되, 구현이 가능해야하는 모델이 산출되야 잘 만들어진 모델이라 할 수 있다.
현실로 다시 돌아와서, 현실에서의 우리(상당히 많은 개발자들)는 도메인 전문가를 매 상황마다 모실 수가 없다. 혹은 내가 ‘First Penguin’이라면? 내가 도메인 전문가가 되어야 한다. 적어도 전문가가 되려고 노력해야 한다. 분석을 토대로 모델링을 할 때, 모델링 하기 편한 모델링이 아니라 당면한 domain의 본질을 담기 위한 모델링을 해야한다.
DDD 를 하기 위한 준비물 2가지
Ubiquitous Language
domain 전문가와 원활하고 지속적인 대화를 해야한다. 개발자들은 domain 전문가의 용어를 이해하고, 이해한 바를 모델에 풀어낸다. 도메인에 대한 지적 탐구를 지속해야 하고 종래에는 개발자도 domain 전문가가 하는 모든 용어를 알아들을 수 있어야 한다. 그들과 같은 언어와 배경지식을 공유해야 모델링 하는데 있어서 domain을 잃지 않을 수 있다.
Model Design Driven
그토록 중요한 모델이 생명력을 잃지 않고 지속적으로 관리되고, domain의 본질을 잃지 않게 유지하는 것이 Model Design Driven 이다. 모델이 생명력을 잃지 않기 위해 몇가지 패턴들이 쓰인다.
DDD 를 위한 패턴들
계층형 아키텍쳐
소프트웨어를 설계할 때, 항상 목적성을 지녀야 한다.
목적성에 맞게 필요한 모듈들을 모을 수 있어야 한다.
Entity
식별자가 있고 영속성이 필요한 Object를 entity라고 한다. 반드시 식별자가 있어야 하고, 식별자가 같으면 같은 Object 인 것이 보장되어야 한다.
Value Object
Entity와 비슷한데, 식별자가 없고, 영속성이 필요하지 않은 Object들.
Service
상태정보를 관리하지는 않지만, 행위 자체를 담당하는 것들을 Service 라고 칭한다.
Aggregation
외부에서 접근하는 방법은 하나지만, 하나의 단위로 간주되는 관련된 객체들의 집합이다. transaction, 데이터의 무결성 등을 처리하기에 용이하다.
Factory
복잡한 절차를 지닌 Entity 들의 생성을 Factory로 묶어서 생성을 관리한다.
Repository
객체를 저장하는 일을 담당하는 녀석이다.
간략하게 DDD 에 대해 정리해 봤고, 다음번는 DDD를 위한 패턴들 이야기와 애자일 이야기를 좀 더 하려고 한다.
글을 쓰기 위해 도움을 얻었던 글목록