• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

확장성 관점에서 Value Object, Entity, Aggregate

23.10.12 12:11 작성 조회수 198

0

강의 잘 듣고 있습니다!

강의 듣고 SNS 프로젝트를 DDD를 적용시켜보려고 하는데,

서비스 초기에는 Value Obejct 였던 것이 Entity가 될 수 있고,

Entity였던 것이 Aggregate 가 될 수 있는 등 서비스가 커짐에 따라 변경될 수도 있나요?

답변 1

답변을 작성해보세요.

1

도메인 주도 설계(Domain-Driven Design, DDD)의 전술적 설계는 서비스가 성장하고 도메인에 대한 이해가 더 깊어지면 진화할 수 있습니다. DDD에서 엔티티(Entities), 밸류 오브젝트(Value Objects) 및 어그리게이트(Aggregates)는 모두 도메인 모델의 구성 요소로, 서로 다른 목적을 가집니다.

  1. 엔티티가 어그리게이트로 변하는 경우: 엔티티가 관련된 엔티티 및 밸류 오브젝트의 복잡하고 연결된 집합을 가지게 되면 어그리게이트로 진화할 수 있습니다. 어그리게이트는 데이터 일관성을 유지하고 포함된 엔티티와 밸류 오브젝트에 대한 액세스를 제어하는 데 사용됩니다.

  2. 밸류 오브젝트가 엔티티로 변하는 경우: 도메인에 대한 이해가 깊어지면 처음에 밸류 오브젝트로 모델링한 개념이 독립적인 식별성을 가져야 한다고 깨닫게 될 수 있습니다. 이런 경우 해당 개체는 고유하게 식별 가능하며 독립적으로 관리되어야 할 필요가 있을 수 있습니다.

전술적 설계의 이러한 변경은 도메인의 진화하는 요구사항과 더 나은 도메인 이해에 따라 이뤄져야 합니다. 이러한 변경 사항이 애플리케이션의 아키텍처, 데이터베이스 설계 및 데이터 액세스 및 업데이트 처리 방식에 영향을 미칠 수 있다는 점을 염두에 두어야 합니다. 따라서 도메인 모델의 데이터 일관성과 무결성을 보장하기 위해 이러한 변경 사항은 신중하게 고려하고 계획되어야 합니다.

DDD는 반복적인 프로세스이며 초기 모델이 프로젝트가 진행됨에 따라 진화하고 도메인에 대한 더 많은 지식이 획득되면 일반적으로 수정됩니다. 도메인 모델을 리팩터링하는 것은 도메인 주도 설계 프로세스의 자연스러운 부분으로, 소프트웨어가 비즈니스 도메인의 진화하는 요구사항과 일치하도록 보장합니다.

백린이님의 프로필

백린이

질문자

2023.10.13

"밸류 오브젝트가 엔티티로 변하는 경우"에 대한 예시를 생각해봤는데요. 혹시 이게 예시가 될 수 있을까요?

 

예를 들어, 서비스 초기에는 알림 설정 기능인 활성화/비활성화 정도만 있어서, 값 객체로 관리하고 있었는데, 서비스가 점점 커지면서 기능이 추가되면서 기능마다 알림을 설정하게 되어 엔티티로 관리하는 경우요!