1장. DDD를 시작하며 / IDDD (도메인 주도 설계 구현)

개요

---

# 참고

IMPLEMENTING DOMAIN DRIVEN DESIGN (도메인 주도 설계 구현) - 반 버논 지음

 

# 개요

DDD에 대한 기술서적을 읽고 DDD가 무엇인지 이해하고 어떻게 코드에 적용시킬 수 있는지 고민해 보려고 한다.

 

1장에서는 DDD를 사용하며 얻을 수 있는 이점이 무엇이며, 왜 DDD를 사용해야 하는지 알아보고자 한다.

 

---

1장. DDD를 시작하며

1-1. DDD는 적용하는 것이 어려울까?

DDD란 분명히 기술적으로 어려운 것은 맞다. 그러니 많은 개발자들이 DDD를 공부하려고 하는 것이라고 생각한다. 하지만 DDD를 적용한다면 분명 얻을수 있는 이점은 확실하다. DDD를 적용하면 다음 이점을 얻을수 있을것이라고 본다.

 

• 애자일을 넘어 비즈니스 영역의 깊은 통찰
• 테스트 주도를 넘어서 정교한 비즈니스 서비스 구현
• 변형이 가능하며, 정교하게 만들어진 고품질의 소픝트웨어

 

---

 

1-2. 왜 DDD를 해야 할까?

비즈니스의 지식은 절대 중앙화되지 않는다. 일반적으로 도메인 전문가는 비즈니스 가치를 제공하는 데 집중하는 한편 소프트웨어 개발자는 전형적으로 기술과 비즈니스 문제점의 기술적 해결에 더 관심을 갖는다. DDD에서는 도메인 전문가와 소프트웨어 개발자의 협업을 중요시 여긴다. 또한 이러한 협업에 사용되는 언어는 유비쿼터스 언어로서 팀원 전체가 함께 사용할 수있는 유비쿼터스 언어를 선택해서 지속적이고 애자일 방법론의 협업을 중요시 한다. DDD의 이점은 다음과 같다.

 

• DDD는 도메인 전문가와 소프트웨어 개발자가 비즈니스 전문가의 심적 모델을 반영한 소프트웨어를 함께 개발할 수 있게 해준다.
• DDD의 전략적 설계 접근법은 기술적 측면과 비즈니스의 문제를 명확하게 결합하고 해결하는 것을 목표로 한다. 따라서 서비스 지향 아키텍처(SOA)와 비즈니스 주도 아키텍처를 성공시킬 수 있도록 해준다.

 

---

1-3. Rich Domain Model  vs Anemic Domain Model

DDD에서는 리치 도메인 모델과 애니믹 도메인 모델에 대해서도 언급하고 있다. DDD를 구현한다면 분명 리치 도메인 모델도 자연스럽게 구현할 수 있을 것이다.

 

---

1-4. 유비쿼터스 언어

DDD의 가장 강력한 요소 중 하나인 유비쿼터스 언어라는 개념이 있다. 유비쿼터스 언어는 바운디드 컨텍스트와 함께 DDD를 구성하는 기둥이다. 유비쿼터스 언어는 팀 내에 공유되는 언어이다. 유비쿼터스 언어는 도메인 전문가와 개발자 간에 같이 공유된다. 그리고 프로젝트에 참가하는 모든 사람 간에 공유된다. 

 

• 유비쿼터스 언어는 팀원 간에 사용되고 팀이 개발하는 하나의 도메인 모델로 발현한다.
• 워비쿼터스는 바운디드 컨텍스트 하나당 하나씩 존재한다.

 

---

1-5. DDD를 사용하면 얻는 비즈니스 가치

 

1. 조직이 그 도메인에 유용한 모델을 얻는다.

DDD의 초점은 비즈니스적으로 중요한 곳에 우리의 노력을 투자한다는 점이다. 과도한 모델링을 하지 않으며 핵심 도메인에 초점을 맞추는 것이다. 지원 도메인도 중요한 역할을 하지만 핵심 도메인과 같은 노력을 들일 수는 없다. 따라서 비즈니스를 차별화하여 경쟁적 우위를 달성하는 것이 중요하다.

 

2. 도메인 전문가가 소프트웨어 설계에 기여한다.

개발자는 도메인 전문가의 개념과 용어는 동일하지 않다. 같은 조직 내에서도 다른 길을 걸어왔기 때문에 분명 차이가 생긴다. 하지만 DDD를 적용하기 위해서는 개발자와 도메인 전문가의 의견이 일치하고 협업하는 것이 중요하다. 개발자와 도메인 저눔가의 의견이 일치한다면 비즈니스 자체를 전반적으로 강화 시킬수 있다. 따라서 개발자와 도메인 전문가는 유비쿼터스 언어를 통해 공통 언어를 공유하는 것이 중요하다. 절대, 선택된 소수만이 모델을 이해하고 비즈니스 문제를 해결하며 결정하는 일은 없어야 한다. 

 

3. 순수한 모델 주번에 명확한 경계가 생긴다.

기술 팀은 비즈니스에 이득이 되는 방향으로 지향점을 맞춰감으로써, 프로그래밍과 알고리즘적 문제에 더 많은 관심을 드러내지 않도록 권장된다. 방향의 순수성은 가장 중요한 곳에 노력을 집중할 수 있도록 함으로써 해결책의 효과에 초점을 맞추도록 해준다.

 

4. 엔터프라이즈 아키텍처의 구성이 좋아진다.

바운디드 컨텍스트를 잘 이해하고 신중하게 분할한 경우 어디서 왜 통합이 필요한지 분명하게 이해하게 된다. 더불어 전체 엔터프라이즈 아키텍처를 아주 철저하게 이해할 수 있도록 해준다.

 

5. 애자일하고, 반복적이고, 지속적인 모델링이 사용된다.

DDD는 설계와 개발 프로세스의 단계가 복잡하게 나눠지지 않는다. DDD는 어떻게 다이어그램을 그리는지에 관한 문제가 아니다. DDD는 도메인 전문가의 심적 모델을 신중히 정제해서 비즈니스에 유용한 모델로 만드는 방법에 관한 문제다. 팀이 익숙한 애자일 프로세스라면 모두가 DDD를 성공적으로 사용할 수 있을 것이다.

 

---

 

1-6. DDD & 테스트 & 애자일

DDD는 애자일 프로젝트와 잘 맞는다. 또한 DDD는 테스트 우선 방식에 따라 실제 소프트웨어 모델을 빠르게 정제해나가는 방식에 더 가깝다. 

 

도메인 모델의 클라이언트가 새로운 도메인 객체를 사용하는 방법을 보여주는 테스트를 작성하라

새로운 도메인 객체를 만들 때는 테스트를 컴파일할 수 있을 정도록 충분한 코드를 함께 작성하라

도메인 객체를 사용하는 방법을 제대로 나타내고, 도메인 객체가 올바른 행동적 메소드 시그니처를 갖게 될 때 까지 리팩토링하라

 

DDD는 사실 테스트 우선 접근법과 다를 바가 없다. 테스트를 수행하는 것은 모델이 완전 무결하다는 절대적 확신을 위해 하는 것이 아니다. 클라이언트가 모델을 사용하는 방법에 초점을 맞추며, 테스트는 모델의 설계를 주도하게 된다. 이것이야말로 진정으로 애자일한 접근법이라는 것이다. DDD는 경량 개발을 추구하지, 단계가 많고 무겁고 선행투자가 필요한 설계는 아니다. 이러한 관점에서 DDD는 일반적인 애자일 개발과 별로 다르지 않다.