DDD(Domain Driven Dsign)

시작하기 전

현재 서비스 개발을 하는 부분에 있어서 해당 방식을 적용하려고 하는 이유가 무엇인지 알고 보는 것이 이해하는데 더욱 도움이 된다고 볼 수 있겠습니다. 어떤 서비스든 초기 버젼 개발 시에는 빠르고 간단하게 만들기 위해 개발자가 편한 대로 개발을 하는 경향이 있습니다. 이러한 프로젝트들은 Version 1 출시 까지는 무난히 운영이 될 수 있겠지만 이후 Version 2 부터는 코드를 리팩토링 하거나 새로운 기능을 추가를 한다고 하였을 때 많은 시간을 투자하게 됩니다.

이러한 상황처럼 이후 개발자들이 비효율적인 시간을 줄이고자, 실제로 적용해야 하는 서비스 들을 좀 더 세분화하고자 사용 되는 접근법이 DDD 입니다.

---

정의

도메인 주도 설계(Domain-Driven Design, DDD)는 소프트웨어 개발을 위한 설계 및 개발 패러다임 중 하나로, 복잡한 도메인을 이해하고 모델링 하는데 초점을 맞춘 접근법입니다. 이 접근 방식은 비즈니스 도메인과 소프트웨어 간의 강력한 결합을 강조하여 개발자, 도메인 전문가, 프로젝트 관계자 간의 소통과 협력을 촉진합니다. DDD를 사용하면 복잡한 도메인을 다루고 이해하는 데 도움이 되며, 이를 바탕으로 효과적이고 유지 보수가 용이한 소프트웨어를 개발할 수 있습니다.

 

이러한 접근법을 활용한다고 하여도 개발에서의 모든 문제들을 해결해 주지 않습니다. 하지만 이러한 방법을 통해 차후에 생길 문제들의 이펙트를 줄이고자 하는 것의 의의를 두는 것이 바람직하다고 생각합니다.

---

특징

• 기존에 많이 사용되는 데이터 주도 설계 방식이 아닌 로직에 집중하여 도메인을 설계하는 도메인 주도 설계 방식을 이용합니다.
  • 해당 방식을 활용하게 되면 도메인의 활용이 다양해지고 데이터가 풍부해집니다.
• 유비쿼터스(Ubiquitos) 언어를 사용 함으로써, 다양한 분야의 전문가가 모여서 도메인에 대한 이해도와 차후에 생길 이해 충돌에 대한 코스트(Cost) 비용이 절감되는 효과를 얻을 수 있습니다.
• 소트프웨어 엔티티와 도메인 컨셉을 최대한 일치화를 시킬 수 있습니다.
  • 요청자가 생각하는 요구사항을 최대한 소프트웨어에 적용하게 함으로써 달성하고자 하는 목표에 좀 더 다가 갈 수 있습니다.
• 서비스의 확장성 부분에서 유연하게 대처 할 수 있습니다.
  • MSA (Micro Service Achitecture) 에 활용 되는 접근 방식으로 이후에 추가적인 요구사항이 들어와도 큰 Waste Cost가 없이 서비스를 추가 할 수 있습니다.

---

용어 정리

용어	의미
유비쿼터스 랭귀지 (Ubiquitous Language)	유비쿼터스 랭귀지는 비즈니스 도메인 전반에서 사용되는 공통 언어로, 비즈니스 전문 용어와 개발 용어가 일치하도록 노력합니다. 도메인 전문가와 개발자는 동일한 용어를 사용함으로써 서로의 의사소통을 원활하게 하고, 도메인의 복잡성을 이해하고 모델링하는데 도움이 됩니다.
도메인 (Domain)	소프트웨어가 적용되는 비즈니스 영역 또는 분야를 나타냅니다. 예를 들어, 은행 시스템에서 고객, 계좌, 거래 등은 해당 도메인에 속하는 요소들입니다.
도메인 모델 (Domain Model)	도메인을 이해하고 표현한 것으로, 비즈니스 개념과 규칙을 소프트웨어 객체로 매핑한 것입니다. 도메인 모델은 소프트웨어의 핵심 부분으로 도메인의 복잡성을 단순화하고, 비즈니스 요구사항을 해결합니다.
엔티티 (Entity)	엔티티는 비즈니스 도메인에서 중요한 개념을 표현하는데 사용됩니다. 도메인 모델링을 통해 실제 비즈니스에 존재하는 사물이나 개념을 엔티티로 추상화하여 소프트웨어에서 표현하게 됩니다
애그리게이트 (Aggregate)	관련된 엔티티와 밸류의 그룹을 하나의 단위로 취급하는 패턴입니다. 애그리게이트 루트라는 주요 엔티티가 그룹의 일부를 관리하고, 다른 객체들은 이 루트를 통해서만 접근할 수 있습니다. 데이터의 일관성과 불변성을 보장하며 도메인 모델을 구조화하는 데 도움이 됩니다.
바운디드 컨텍스트 (Bounded Context )	복잡한 도메인을 논리적으로 분리하여 개별적인 영역으로 정의하는 방법입니다. 바운디드 컨텍스트는 소프트웨어 시스템을 구축하는데 필요한 모델과 언어를 특정한 도메인 영역 내에서만 유효하도록 제한합니다. 이렇게 하면 도메인의 복잡성을 다루기 쉽고, 다른 영역과의 관계에서 발생할 수 있는 혼란과 충돌을 최소화할 수 있습니다.
컨텍스트 맵 (Context Map)	바운디드 컨텍스트(Bounded Context)들 간의 상호작용과 관계를 시각적으로 표현하는 도구입니다.

---

전략적 접근, 전술적 접근

DDD는 크게 전략적 접근(Strategic Design)과 전술적 접근(Tactical Design)으로 구분됩니다.

1. 전략적 접근 (Strategic Design): 전략적 접근은 프로젝트의 큰 그림을 이해하고 도메인 전반적인 구조를 설계하는 단계입니다. 주로 도메인의 경계, 서브도메인, 바운디드 컨텍스트 등을 정의하고 조직 전체의 비즈니스 목표와 도메인을 이해하는데 초점을 둡니다.
   • 바운디드 컨텍스트 (Bounded Context): DDD에서는 도메인을 다양한 바운디드 컨텍스트로 분리합니다. 각 바운디드 컨텍스트는 자체적인 모델과 비즈니스 룰을 가지며, 이를 통해 도메인의 경계를 명확하게 정의합니다. 이렇게 하면 큰 규모의 프로젝트에서 도메인 간의 복잡한 상호작용을 간소화할 수 있습니다.
   • 컨텍스트 매핑 (Context Mapping): 서로 다른 바운디드 컨텍스트 간의 상호작용을 정의하는 것을 말합니다. DDD에서는 컨텍스트 매핑을 통해 바운디드 컨텍스트 간의 인터페이스와 커뮤니케이션을 정의하여 유연하고 효과적인 시스템을 구축합니다.
2. 전술적 접근 (Tactical Design): 전술적 접근은 단일 바운디드 컨텍스트 내에서 모델과 엔티티, 그리고 리포지토리 등의 구현을 다루는 단계입니다. 전략적 접근에서 정의한 바운디드 컨텍스트를 실제로 구현하고, 도메인 모델과 비즈니스 로직을 작성하는 단계입니다.
   • 엔티티 (Entity): 도메인에서 식별 가능한 객체를 나타냅니다. 엔티티는 도메인에서 가장 중요한 개념 중 하나로, 유니크한 식별자를 가지고 있습니다. 이러한 엔티티들은 도메인의 핵심 비즈니스 로직을 포함하며, 도메인의 상태를 변경하거나 도메인 이벤트를 발생시키는 역할을 수행합니다.
   • 리포지토리 (Repository): 엔티티를 저장하고 검색하는 인터페이스를 제공하는 패턴입니다. 리포지토리를 사용하여 엔티티의 영속성(데이터베이스에 저장)을 처리하며, 도메인 로직과 데이터베이스 접근 로직을 분리하여 도메인 모델의 의존성을 낮춥니다.
   • 값 객체 (Value Object): 엔티티와 다르게 식별자를 가지지 않고, 속성으로만 구성되는 객체를 나타냅니다. 값 객체는 불변(Immutable)해야 하며, 두 개의 값 객체가 같은 속성 값을 갖으면 동등하다고 판단합니다. 주로 도메인 모델 내에서 공유되는 간단한 객체를 값 객체로 정의합니다.

전략적 접근은 프로젝트를 시작할 때 중요하며, 전술적 접근은 실제 도메인 로직을 구현할 때 중요합니다. DDD를 통해 복잡한 도메인을 명확하게 분리하고, 비즈니스 요구사항을 잘 반영하는 유지보수 용이한 시스템을 구축할 수 있습니다.

---

순서