-
도메인 주도 설계 - 6. 도메인 객체의 생명주기(AGGREGATE, FACTORY, REPOSITORY)디자인 패턴 2024. 4. 24. 09:44
본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.
이해가 어려우시다면 댓글 부탁드립니다.
AGGREGATE(집합체)
AGGREGATE는 데이터 변경의 단위로 다루는 연관 객체의 묶음 개념이다. 복잡한 연관관계를 맺는 객체를 대상으로 일관성을 보장한다. 각 AGGREGATE에는 루트(root)와 경계(boundary)가 있고 루트는 단 하나만 존재하고 특정 ENTITY를 가리킨다. 경계안에 객체는 서로 참조 가능하다. 경계 바깥 객체(또 다른 AGGREGATE)는 루트만 참조 가능하다. 지역 식별성은 AGGREGATE내에서만 구분하면 된다.
예를 들어, 자동차는 전역 식별성을 가진 ENTITY이다. 네개의 바퀴는 식별할 수 있다면 지역 식별성을 가진다. 그러나 엔진부에 일련번호가 새겨져 있어서 자동차와는 무관하게 추적되기도 한다. 다른 애플리케이션에서는 엔진이 자체적인 AGGREGATE가 될 수도 있다.
AGGREGATE를 구현하기 위한 모든 트랜잭션에 적용되는 규칙
- 루트 ENTITY는 전역 식별성을 가지고 불변식을 검사할 책임을 가짐
- 경계 안의 ENTITY는 지역 식별성을 지님 (AGGREGATE내에서만 유일)
- AGGREGATE는 서로 루트만 참조 가능하고 내부 구성요소는 참조할 수 없음. 루트가 내부 ENTITY의 참조를 전달할 수는 있지만 일시적으로만 사용해야 함. VALUE OBJECT는 자유롭게 전달 가능
- DB 질의시 AGGREGATE의 루트만 직접적으로 획득할 수 있음
- 삭제시 경계안의 모든 요소를 한 번에 제거해야 함
FACTORY(팩토리)
FACTORY는 전체 AGGREGATE를 생성하는 일이 복잡해서지거나 내부 구조를 너무 드러낼 경우에 캡슐화해주는 개념이다. 예를 들어 자동차 애플리케이션에서 자동차를 하나하나 특정 엔진, 특정 타이어 등을 조립해서 하나의 객체를 만들어서 사용될 것이다. 비지니스에서 자동차 객체를 사용하는 것에만 가치가 있지 조립해서 만드는 일은 그다지 중요한 일이 아니다. FACTORY는 이러한 복잡한 복합 객체를 조립하는 일을 담당한다
어떤 객체를 생성하는 것이 그 자체로도 주요한 연산이 될 수 있지만 복잡한 조립 연산은 생성된 객체의 책임으로 어울리지 않는다. 이런 책임을 클라이언트에 두면 이해하기 힘든 설계가 만들어 질 수 있다. 자신의 책임이 다른 객체를 생성하는 것인 요소를 FACTORY라 한다.
REPOSITORY(리파지터리)
데이터베이스로부터 도메인 모델 객체를 CRUD 시 AGGREGATE 루트로만 참조를 할 수 있도록 직접적인 참조를 캡슐화하는 개념이다. 모든 객체 저장과 접근은 REPOSITORY가 책임을 가지고 클라이언트는 모델에 집중할 수 있도록 한다. 모든 REPOSITORY는 클라이언트가 특정 기준에 부합하는 객체를 요청할 수 있는 메서드를 제공한다. REPOSITORY는 클라이언트가 진 큰 부담을 덜어주고 클라이언트는 단순한 의도를 드러내는 인터페이스로 소통한다.
REPOSITORY의 장점
- DB에 있는 데이터를 객체로 가져오고 해당 객체의 생명주기를 관리하기 위한 모델을 클라이언트에게 제시
- 영속화 기술과 다수의 데이터베이스 전략으로부터 애플리케이션과 도메인 설계를 분리한다
- 객체 접근에 대한 설계를 결정
- 테스트시 가짜 구현으로 대체할 수 있음
명심해야할 중요한 사항
- 타입을 추상화: REPOSITORY가 반환하는 객체 타입을 추상화할 수도 있음(TradeOrder로 추상화하면 SellOrder나 BuyOrder가 될 수도 있음)
- 클라이언트와의 분리를 활용: 이렇게 하면 클라이언트에서 직접 질의할 때보다 더 자유롭게 REPOSITORY의 구현을 변경할 수 있고 영속화 전략을 바꿔가면서 캐싱 등 최적화를 수행할 수 있음
- 클라이언트가 트랜잭션 커밋 제어: 데이터베이스에 대한 삽입과 삭제를 REPOSITORY가 수행하지만 아무것도 커밋하지 않음. 클라이언트가 올바르게 단위작업을하고 커밋할 수 있도록하면 트랜잭션 관리가 더 단순해짐
'디자인 패턴' 카테고리의 다른 글
도메인 주도 설계 - 9. 암시적인 개념을 명확하게 (0) 2024.05.02 도메인 주도 설계 - 8. 도약 (0) 2024.04.26 도메인 주도 설계 - 5. 소프트웨어에서 표현되는 모델(ENTITY, VO, ...) (1) 2024.04.19 도메인 주도 설계 - 4. 도메인의 격리 (0) 2024.04.15 도메인 주도 설계 - 3. 모델과 구현의 연계 (0) 2024.04.09