[개발] DDD, 도메인 주도 설계 용어 정리 해보기!

오늘은 DDD, 도메인 주도 설계 방법론에서 사용되는 용어에 대한 정리를 해볼까 합니다.

제가 요즘 DDD 공부를 하고 있는데 책에 듣지 못했던 용어들이 사용되어 계속 찾아보는 불편함을 느끼고 있습니다. 

 

읽어도 그 순간에는 ㅎ 이해하는데 시간이 지나고 다시보면 좀 했갈리고 실제 코드의 구현과 매핑이 잘 안되기도 해서

스스로 공부를 위해 정리해봅니다!

 

자 그럼 일단 간략히 DDD란 무엇인지 부터 정리해보겠습니다!

1. DDD란? 도메인 주도 설계란?

도메인 주도 설계(DDD, Domain-Driven Design)는 소프트웨어 시스템의 복잡성을 다루기 위한 개발 방법론 중 하나입니다. DDD는 도메인, 즉 비즈니스 영역에 중점을 두고 시스템을 설계하고 개발하는 방법론으로, 도메인 모델링, 팀 간 소통, 유비쿼터스 언어 등의 요소를 강조합니다.

2. 유비쿼터스 언어란? Ubiquitous Language란?

개발자, 도메인 전문가, 비즈니스 팀 간에 공유되는 도메인 특화 언어를 의미합니다. 모든 이해 관계자가 동일한 용어를 사용하여 소통할 수 있도록 도움을 줍니다.

3. 도메인이란? Domain?

도메인이란 비즈니스의 핵심적인 부분 또는 영역을 가르키는 용어로 시스템이나 스프트웨어가 해결하려 하는 문제의 영역을 나타냅니다.

4. 엔티티란? Entity?

    도메인 모델에서 독립적으로 존재하며 식별 가능한 객체를 나타냅니다. 각 엔티티는 고유한 식별자를 가지고 있습니다.

• Entity (엔터티):
  • 예시: 상품(Product)
  • 설명: 각 상품은 고유한 식별자를 가지며, 상품의 속성 중 일부(예: 가격, 이름)는 변경될 수 있습니다. 상품이라는 엔터티는 식별 가능하고 상태를 가지며, 일정 기간 동안 유지되는 개념입니다.

5. 값 객체란? Value Object?

    고유성이 아닌 특성에 의해 식별되는 객체를 나타냅니다. 값 객체는 불변하며, 동일한 속성을 가진 경우 서로 동등합니다.

• Value Object (값 객체):
  • 예시: 주소(Address)
  • 설명: 주소는 특정한 상태를 나타내는데, 주소의 값 자체가 중요합니다. 두 개의 주소가 동일한지 여부는 주소의 내용에 기반하여 결정됩니다. 또한, 주소의 값은 불변적이어야 합니다.

저는 이부분에서 Value Object가 좀 했갈렸는데 구현 코드들과 설명들을 보니 이해가 갔습니다. 이 부분에 대해서는 나중에 별도의 글로 다뤄보도록 하겠습니다. (예약글 : Value Object와 Entity의 차이) 

 

Value Object의 특징:

1. 불변성(Immutability): 값은 수정되지 않아야 합니다. 변경이 필요한 경우에는 새로운 객체를 생성해야 합니다.
2. 동일성(Identity): 두 개의 객체가 같은 속성을 가지면 동일한 것으로 간주됩니다.
3. 비즈니스 불변 규칙: 객체의 수정은 새로운 객체를 생성하고, 해당 객체를 참조해야 합니다. 이를 통해 불변성을 유지하며, 객체 간의 의존성을 관리할 수 있습니다.

class Address:
    def __init__(self, street, city, zip_code):
        self.street = street
        self.city = city
        self.zip_code = zip_code

# 주소 객체 생성
address1 = Address("123 Main St", "Cityville", "12345")
address2 = Address("123 Main St", "Cityville", "12345")

# 두 객체는 값이 동일하므로 동일한 것으로 간주됨
print(address1 == address2)  # True

 

6. 애그리게이트란? Aggregate?

    연관된 엔티티와 값 객체의 그룹을 나타냅니다. 애그리게이트는 논리적으로 하나의 단일 단위로 취급되며, 루트 엔티티를 통해 액세스 됩니다.

• Aggregate (애그리게이트):
  • 예시: 주문(Order)
  • 설명: 주문은 여러 개의 상품 아이템, 배송 주소 등을 포함하는 복합적인 구조를 가지며, 이를 하나의 주문으로 묶어 표현합니다. 주문은 애그리게이트 루트(Entity) 역할을 하며, 주문에 속하는 상품 아이템들은 일종의 애그리게이트 내부의 일부로 간주됩니다.

7. 리포지터리란? Repository란? 

    도메인 객체를 영속적으로 저장하고 검색하는 인터페이스를 제공하는 패턴입니다. 리포지터리는 도메인모델과 데이터베이스 간의 인터페이스 역할을 합니다. 

8. 도메인 주도 설계에서 서비스란? DDD 에서 Service란? 

    특정 도메인 로직을 수행하는 무상태의 객체를 나타냅니다. 엔티티나 값 객체로 표현하기 어려운 특정한 도메인 로직을 처리합니다.

9. 도메인 이벤트란? Domain Event란?

    도메인에서 발생하는 중요한 사건을 나타내는 것으로 시스템의 다양한 부분 간의 통신과 도메인 모델의 변경을 트리거 할 수 있습니다.

10. 바운디드 컨텍스트란? Bounded Context?

바운디드 컨텍스트란 큰 시스템을 여러개의 작은 컨텍스트로 나누어 각 컨텍스트 내에서 특정한 비즈니스 규칙과 데이터 모델이 적용 되는 것을 의미합니다. 각 컨텍스트는 독립적으로 설계되고 도메인 안에서 특정한 비즈니스 문제 영역을 나타내며 그 영역 안에서 용어, 개념, 규칙등이 일관되게 적용됩니다. 도메인을 작은 단위로 분리, 바운디드 컨텍스트를 식별하여 독립적으로 동작하도록 설계, 구현 하여 전체 도메인 시스템의 복잡성을 줄이고 유연성을 높이는 역할을 합니다.   

 

바운디드 컨텍스트는 서로 다른 서브 도메인간의 경계를 나타내며, 서로 다른 바운디드 컨텍스트 내에서는 동일한 용어라도 다르게 해석 될 수 있습니다. 이를 통해서로 다른 영역의 모델간에 간섭이 줄어들고, 각각의 바운디드 컨텍스트 내에서 개발이 더 수월해 질 수 있습니다.

11. 서브 도메인이란? Subdomain?

    바운디드 컨텍스트 내에서 다루는 특정 비즈니스 영역을 말합니다.

 

예시로 온라인 쇼핑몰 도메인이라면 서브 도메인은 아래와 같을 수 있습니다.

 

가정: 온라인 쇼핑몰 도메인

• 바운디드 컨텍스트 1: 주문과 결제 서브 도메인
  • 서브 도메인: 주문, 결제
  • 여기에서 정의된 주문과 결제에 대한 모델, 용어, 로직이 해당 바운디드 컨텍스트에서 유효합니다.
• 바운디드 컨텍스트 2: 상품 서브 도메인
  • 서브 도메인: 상품, 재고

여기에서 정의된 상품과 재고에 대한 모델, 용어, 로직이 해당 바운디드 컨텍스트에서 유효합니다.

 

이름은 같지만 다른 역할

- 카탈로그 도메인 : 상품 (상품 이미지, 상품명, 가격)

- 재고 관리 도메인 : 상품(실존하는 개별 객체를 추적하는 목적)

 

이름은 다르지만 같은 역할

- 회원 도메인 : 회원

- 주문 도메인 : 주문자

- 배송 도메인 : 보내는 사람 

12. 도메인 모델이란? Domian Model?

도메인 모델이란 도메인에 대한 이해를 토대로 시스템을 모델링한 것을 의미합니다. 도메인 모델은 엔티티, 값 객체, 애그리게이트 등의 요소로 구성됩니다. 

 

도메인 모델 패턴 - 일반적인 애플리케이션의 아키텍처는 다음과 같이 네 개의 계층으로 구성된다고 한다.

 

- Presentaition (표현 또는 사용자 인터페이스(UI)

사용자의 요청에 대하여 해석하고 응답하는 일을 하는 계층

사용자는 소프트웨어를 사용하는 사람 뿐 아니라 외부 시스템일 수 있다.

사용자에게 UI를 제공하거나 클라이언트의 응답을 다시 보내는 역할을 하는 모든 클래스가 포함

 

- Application (응용)

비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 인프라스트럭쳐 계층을 열결해주는 계층

비즈니스 로직은 구현하지 않으며, 도메인 계층을 조합해서 기능을 실행

실질적 데이터 처리는 도메인 계층에서 진행 할 수 있도록 위임하는 것이 중요

 

- Application 계층에 포함 것들

1) 트랙잭션의 단위

2) DTO 변환

3) 엔티티 조호 및 저장

 

- Domain (도메인)

비즈니스 규칙, 정보에 대한 실질적인 도메인 정보를 가지고 있으며 그것을 책임지는 계층

Entity를 활용하여 도메인 로직이 실행, 업무 상황을 반영하여 상태를 제어하는 역할에 집중하는 계층

 

- Inrastructure (인프라스트럭처)

외부와의 통신(DB, 메세징 시스템등)을 담당하는 계층

해당 계층에서 가져오는 정보들을 Application 계층, Domain 계층으로 전달하는 역할

 

-------------------------------------------------------------------------

 

정리하다보니 너무 길어졌습니다. 와... 이해해야 될 내용이 많네요 ㅎㅎ 어렵다기보다 명확한 정의가 머리속에 내려지지 않아서 구현과 접목 시키는게 복잡해지는 것 같습니다.  더 공부해야겠군요!

 

나중에 해당 글 내용 중 예약글 로 표기된 글들은 추가로 작성해보도록 하겠습니다!!

 

틀린 부분 또는 추가적인 내용은 댓글로 달아주시면 감사하겠습니다. ㅎ 저도 공부하면서 적다보니 틀릴 수 있어서 ㅎㅎ그럼 이만 꾸벅s