확장성 관점에서 Value Object, Entity, Aggregate
402
작성한 질문수 38
강의 잘 듣고 있습니다!
강의 듣고 SNS 프로젝트를 DDD를 적용시켜보려고 하는데,
서비스 초기에는 Value Obejct 였던 것이 Entity가 될 수 있고,
Entity였던 것이 Aggregate 가 될 수 있는 등 서비스가 커짐에 따라 변경될 수도 있나요?
답변 1
1
도메인 주도 설계(Domain-Driven Design, DDD)의 전술적 설계는 서비스가 성장하고 도메인에 대한 이해가 더 깊어지면 진화할 수 있습니다. DDD에서 엔티티(Entities), 밸류 오브젝트(Value Objects) 및 어그리게이트(Aggregates)는 모두 도메인 모델의 구성 요소로, 서로 다른 목적을 가집니다.
엔티티가 어그리게이트로 변하는 경우: 엔티티가 관련된 엔티티 및 밸류 오브젝트의 복잡하고 연결된 집합을 가지게 되면 어그리게이트로 진화할 수 있습니다. 어그리게이트는 데이터 일관성을 유지하고 포함된 엔티티와 밸류 오브젝트에 대한 액세스를 제어하는 데 사용됩니다.
밸류 오브젝트가 엔티티로 변하는 경우: 도메인에 대한 이해가 깊어지면 처음에 밸류 오브젝트로 모델링한 개념이 독립적인 식별성을 가져야 한다고 깨닫게 될 수 있습니다. 이런 경우 해당 개체는 고유하게 식별 가능하며 독립적으로 관리되어야 할 필요가 있을 수 있습니다.
전술적 설계의 이러한 변경은 도메인의 진화하는 요구사항과 더 나은 도메인 이해에 따라 이뤄져야 합니다. 이러한 변경 사항이 애플리케이션의 아키텍처, 데이터베이스 설계 및 데이터 액세스 및 업데이트 처리 방식에 영향을 미칠 수 있다는 점을 염두에 두어야 합니다. 따라서 도메인 모델의 데이터 일관성과 무결성을 보장하기 위해 이러한 변경 사항은 신중하게 고려하고 계획되어야 합니다.
DDD는 반복적인 프로세스이며 초기 모델이 프로젝트가 진행됨에 따라 진화하고 도메인에 대한 더 많은 지식이 획득되면 일반적으로 수정됩니다. 도메인 모델을 리팩터링하는 것은 도메인 주도 설계 프로세스의 자연스러운 부분으로, 소프트웨어가 비즈니스 도메인의 진화하는 요구사항과 일치하도록 보장합니다.
0
"밸류 오브젝트가 엔티티로 변하는 경우"에 대한 예시를 생각해봤는데요. 혹시 이게 예시가 될 수 있을까요?
예를 들어, 서비스 초기에는 알림 설정 기능인 활성화/비활성화 정도만 있어서, 값 객체로 관리하고 있었는데, 서비스가 점점 커지면서 기능이 추가되면서 기능마다 알림을 설정하게 되어 엔티티로 관리하는 경우요!
애그리거트 질문있습니다!
0
31
2
도메인 질문있습니다
0
47
2
MSA 질문이 있습니다
0
67
1
현재에도 강의와 동일한 방식을 사용하고 계실지 궁금합니다.
0
65
2
다른 BC 또는 마이크로서비스 담당 정보를 어떻게 이용하나요?
0
133
3
VO 관련 궁금한점
0
406
1
VO에 대해서 질문있습니다.
0
402
1
도메인, 바운디드 컨텍스트 관련해서 궁금합니다.
0
790
1
앱에서 DDD를 적용하는 것이 맞는걸까요?
1
747
1
도메인 영역에 대한 질문
0
313
1
클린 아키텍처와 헥사고날 아키텍처 질문
0
488
2
전략적 설계와 전술적 설계
0
314
1
DDD 현실적 적용
1
655
3
애그리거트의 크기
0
584
2
엔티티와 값객체와의 차이
0
560
1
도메인 서비스와 응용서비스의 구분
0
1511
1
Aggreagte 에 두개 이상의 Entity로 구성할 수 있나요?
0
632
1
VO, Entity 궁금한 부분이 있습니다.
1
436
1
안녕하세요. PPT 자료 공유 부탁 드려요.
0
509
1
usecase 작성 단계가 궁금합니다.
0
599
1
대여 도메인 장 관련 문의드립니다.
1
434
1
애그리거트 추출 질문드립니다.
0
596
1
도메인 이벤트 추출관련해서 여쭤보고 싶습니다!
0
467
1
컨트롤러 관련해서 질문이 있습니다!!
0
402
1