6장 도메인 객체의 생명주기

[chanhyeong]

Aggregate

데이터의 변경 단위로 다루는 연관 객체의 묶음, root + boundary

• Customer (Aggregate 외부 객체) 는 Car, Engine 을 를 참조하거나 DB 에서 조회할 수 있음
  • Car 내의 Tire 에 대한 참조는 가질 수 없음

• Car, Wheel, Tire 는 각각 Entity

Rule

1. root entity - Global Identity + responsible for checking invariants (불변함을 검사할 책임)
2. entities in boundary - Local Identity. Aggregate 내에서만 unique
3. Aggregate 외부에서는 root entity 를 제외한 내부 구성요소를 참조할 수 없다
   • 내부 entity 참조 전달은 가능하지만 일시적으로만 사용해야 한다
   • value object 사본 전달은 상관 없음
   • db query 시 root 만 직접 획득 -> 다른 객체는 모두 aggregate 를 탐색
4. aggregate 내 객체는 다른 aggregate 의 root 만 참조할 수 있음
5. 삭제 연산은 aggregate 에 속한 모든 요소를 한 번에 제거해야 함

Factory

aggregate 생성이 복잡해지거나 내부 구조를 너무 많이 드러내는 경우 -> 캡슐화

복잡한 객체 조립 과정을 캡슐화 + 클라이언트가 인스턴스화되는 객체의 구현(concrete) 클래스를 참조할 필요가 없는 인터페이스 제공

형태

factory method, abstract factory, builder

Invariant logic 의 위치

Factory 는 이미 내부 구조를 알고 있고, 구현과 밀접하게 관련이 있으므로 Invariant logic 를 factory 에 두어서 생성물의 복잡한 요소를 줄이는 것도 이점

불변식은 무엇인지 ❓

Repository

ENTITY, VALUE 를 탐색하기 위한 진입점

DDD 의 목표는 기술보다는 도메인에 대한 모델이 집중하는 건데

개발자가 SQL query 를 작성하여 query service 에 보내고 결과를 constructor or factory 에 전달한다면 => 모델에 집중하기 힘들어짐 => 객체를 query 를 통해 제공되는 데이터의 컨테이너로 여기게 됨 => 전체 설계가 데이터 처리 방식으로 나아감

Repository 는 특정 타입의 객체를 하나의 개념적 집합으로 나타낸다

• CrudRepository

Aggregate Root 에만 Repository 를 제공하고 모든 객체 저장과 접근은 Repository 에 위임 -> 클라이언트가 모델에 집중

구현 시

• 타입을 추상화
  • TradeOrder 가 BuyOrder 나 SellOrder 가 될 수 있음
  • concrete class 가 될 수도 있다
  • 이용하는 DB 에서 polymorphism 을 지원하지 않아 제약이 있을 수 있다
• 클라이언트와 분리
• 트랜잭션 제어는 클라이언트에
  • 이래서 트랜잭션이 spring-tx 로 따로 나와있는 듯

[bearics]

6장. 도메인 객체의 생명주기

도메인 객체의 관리에서 가장 중요한 점

• 생명주기 동안 무결성 유지
• 생명주기 관리의 복잡성으로 모델이 난해지는 것 방지

위 사항을 유지하기 위한 스킬

• AGGREGATE(집합체)
• FACTORY(팩토리)
• REPOSITORY(레파지터리)

기존 모델의 한계

1. 개체 참조를 통해 얽히고 설킨 관계망을 가지고 있다
   • 복잡한 연관관계가 많으면 변경의 일관성을 보장하기 어렵다
   • 여러 클라이언트가 동시에 접근 시에도 문제
   • 이를 해결하기 위해서는 모델 근간부터 개선 필요

AGGREGATE

• 데이터 변경 단위로 다루는 연관 객체의 묶음
• root, boundary로 구성
  • boundary는 aggregate에 무엇이 포함되고 포함되지 않는지 정의
  • root는 단 하나이며, 특정 entity를 가리킨다. (= 전역 식별성)
• 경계 안의 객체는 서로 참조 가능하지만, 바깥 객체(다른 aggregate)의 root만 참조 가능
• 루트 이외의 entity는 지역 식별성은 가짐(=agg 안에서는 의미 있음)
• 외부로 VO를 줄때는 복사본으로 전달(주면 더이상 관계X)
• 삭제 연산은 agg 경계 안의 모든 요소를 한 번에 제거

FACTORY

• 캡슐화가 주 목적. 외부에서 도메인 객체의 내부사정을 몰라도 잘 쓸 수 있게
• FATORY가 AGG를 생성할 때 내부적으로 모든 불변식을 만족, 아닐 시 사용못하도록 반환
• FATORY의 위치는 같은 AGG의 root에 있을 수도 있고, 상황에 따라(누가 생산하는지에 따라) 전용 FATORY 객체나 SERVICE로 만듦
• 간단한 경우에는 public constuctor도 가능함.(이거 보다는 FATORY METHOD가 낫지 않을까?)
• 각 연산은 원자적이어야 한다. 생성 시 필요한 것들은 한번에 전달.
• FACTORY는 자신에게 전달된 인자와 결합될 것이다. << 이거 무슨 말이지?(객체 안의 객체를 쓰지 말라는건가. p147)
• 식별성 할당도 FACTORY에서 하면 좋음 << FACTORY도 @Component로 될 수 있나요?
• 재구성에 사용된 ENTITY FACTORY로 사용될 때는 새로운 ID 할당X, 더 복잡한 불변식 포함 (이미 저장된 값이라, 롤백이나 제거까지 필요할지도 모름)

REPOSITORY

• 재구성(reconstitution) = 저장되어 있는 객체 > 인스턴스로 가져오는 것
• 저장 조회 질의 메커니즘을 캡슐화.
• 우리가 알고 있는 repository 기능과 동일(DB와 연결성 분리,CRUD 책임, SQL 분리 등)
• 타입을 추상화한다.(BuyOrder, SellOrder 따로 있는게 아니라 TraderOrder 하나로 충분)
• 트랜잭션 제어를 클라이언트(Application)에 둔다. ** Repository 에서는 commit X

p145 이거 무슨말이징?

Factory에서 어떻게 sequence를 가져오지??

[y2o2u2n]

AGGREGATE

• 데이터 변경의 단위로 다루는 연관 객체의 묶음
• 각 AGGREGATE 에는 루트와 경계가 있음
• 경계는 AGGREGATE 에 무엇이 포함되고 포함되지 않는지를 정의
• 루트는 단 하나만 존재하며, AGGREGATE 에 포함된 특정 ENTITY. 전역 식별성을 지님
• 경계 안의 객체는 서로 참조할 수 있지만, 경계 밖의 객체는 해당 AGGREGATE 의 구성요소 가운데 루트만 참조 가능
• 루트 이외의 ENTITY 는 지역 식별성을 지니며, 지역 식별성은 AGGREGATE 내에서만 구분됨
• 루트 ENTITY 가 내부 ENTITY 에 대한 참조를 다른 객체에 전달할 수 있지만 일시적으로만 사용
• VALUE OBJECT 는 복사본으로 전달하기 때문에 문제 없음
• 삭제 시, AGGREGATE 경계 안의 모든 요소를 한 번에 제거해야 함
• AGGREGATE 경계 안의 어떤 객체를 변경하더라도 전체 AGGREGATE 의 불변식은 모두 지켜져야 함
• ENTITY 와 VALUE OBJECT 를 AGGREGATE 로 모으고 각각에 대해 경계를 정의한 뒤,
• 한 ENTITY 를 골라 AGGREGATE 의 루트로 만들고 AGGREGATE 경계 내부의 객체에 대해서는 루트를 거쳐 접근할 수 있게 해야 함
• AGGREGATE 밖의 객체는 루트만 참조할 수 있게 해야 함
• 내부 ENTITY 에 대한 일시적인 참조는 단일 연산에서만 사용할 때 외부로 전달 가능함
• 루트를 경유하지 않고서는 AGGREGATE 의 내부를 변경할 수 없음
• 위를 잘 이행하면, 모든 불변식을 효과적으로 이행할 수 있음

FACTORY

• 어떤 객체나 전체 AGGREGATE 를 생성하는 일이 복잡해지거나 내부 구조를 너무 많이 드러낼 때 FACTORY 를 사용

REPOSITORY

• 데이터 접근 인프라스트럭처를 적용하는 데 따르는 급격한 기술성 복잡성으로 클라이언트 코드는 복잡해지며
• 도메인 계층에 대한 개발자들의 이해 수준을 낮춰 모델을 도메인 계층과 동떨어진 것으로 만듬.
• 이런 문제를 해결하기 위해 REPOSITORY 를 사용해서 영속화 기술을 캡슐화 해서 클라이언트 코드를 단순하게 만들어야 함
• 객체를 추가하고 제거하는 메서드를 제공하고, 이 메서드가 실제로 데이터 저장소에 데이터를 삽입하고 데이터 저장소에 제거하는 연산을 캡슐화함
• 실질적으로 접근해야 하는 AGGREGATE 의 루트에 대해서만 REPOSITORY 를 제공하고,
• 모든 객체 저장과 접근은 REPOSITORY 에 위임해서 클라이언트가 모델에 집중하게 해야 함

궁금증

• AGGREGATE : 불변식?
• FACTORY : 실제 코드에서는 어떤 형태일지? 흔히 아는 팩토리 패턴?
• REPOSITORY : JPA 를 사용하는 RDB 이외의 데이터 저장소 또는 외부 API 들도 이런식의 구현이 가능할까?

[youngvly]

1. aggregate root에서, db쿼리를 통해서는 루트만 직접적으로 획득할 수 있다. 다른 객체는 모두 aggregate를 탐색해서 발견해야한다 ❓
2. factory를 잘 설계하기위한 조건에서, 생성된 클래스보다는 생성하고자하는 타입으로 추상화되어야 한다.❓
3. repository에서, findOrCreate 기능은 사용을 자제하자는데,, cretaeOrUpdate와도 같은 맥락이겠지? 그럼 대안은??..