[keyword] 6장 - 도메인 객체의 생명주기

[emiling]

주제

'6장. 도메인 객체의 생명주기'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

https://github.com/caffeine-library/Domain-Driven-Design/issues/30

[kth990303]

Aggregate

• Aggregate는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말한다. (p. 131)
• 경계 안의 객체는 서로 참조할 수 있지만, 경계 바깥의 객체는 해당 Aggregate의 구성요소 가운데 루트만 참조할 수 있다. 루트 이외의 Entity는 지역 식별성을 지니며, 지역 식별성은 Aggregate 내에서만 구분되면 된다. (p. 131)
• 한 Entity를 골라 Aggregate의 루트로 만들고 Aggregate 경계 내부의 객체에 대해서는 루트를 거쳐 접근할 수 있게 하라. (p. 133)

에그리거트는 한 개 이상의 Entity와 그와 연관된 VO들을 가지고 있음. 또, 타 에그리거트 간의 연관이 발생하게 될 경우 Deadlock 유의.

Factory

• 복잡한 객체와 AGGREGATE의 인스턴스를 생성하는 책임을 별도의 객체로 옮겨라. (p. 142)

토비의 스프링 1권 1장에서 설명된제어의 역전 내용을 떠올릴 수 있음. 복잡한 객체 및 구현체의 생성 책임을 Factory에게 위임한다. 단, 최근에는 JpaRepository 등 ORM 기술들이 발달하여 Entity 생성을 Repository에서 하는 경우도 많음

이 경우 Repository가 데이터를 근거로 객체를 생성하므로 많은 이들이 Repository를 Factory로 생각하는데, 사실 기술적 관점에서는 그렇다고 볼 수 있다. 그러나 모델을 중심에 두는 것이 더 유용하며, 앞에서 언급한 것처럼 저장된 객체를 재구성하는 것이 새로운 개념적 객체를 생성하는 것은 아니다. (p. 163)

Repository

• 잘 알려진 전역 인터페이스를 토대로 한 접근 방법을 마련하라. (중략) 데이터를 삽입하고 데이터 저장소에서 제거하는 연산을 캡슐화하게 하라. (p. 157) 실제로 Repository 인터페이스의 메서드들은 도메인을 반환하므로 domain 계층에, Repository 구현체는 영속성 기술에 의존하므로 repository 패키지에 두는 케이스도 많음. 또, JpaRepository와 queryDSL을 함께 사용할 경우 최대한 의존성을 적게 하고 캡슐화의 장점을 챙기도록 인터페이스화를 할 수 있음.

• 타입을 추상화한다.

• 클라이언트와의 분리를 활용한다.

• 트랜잭션 제어를 클라이언트에 둔다. (p. 162)

repository의 메서드 하나하나에 트랜잭션을 두기보단 비즈니스 로직에 트랜잭션 제어를 둔다. (ex. 은행 예금 절차가 있을 때, 돈이 나한테서 빠져나가는 것 + 은행에 돈이 들어오는 것은 하나의 트랜잭션으로 묶어야 함.)

(개인적 주관) 단, 비즈니스 로직을 관리하는 서비스 레이어 바깥까지 트랜잭션 제어를 반환하는 것은 반대 (사유: 커넥션 리소스 낭비 및 엔티티 변경감지 작업이 비즈니스 로직 이외에서 발생 가능 https://kth990303.tistory.com/427)

[leejaeseung]

165p

일반적으로 새로운 객체와 이미 존재하는 객체를 구분하는 것은 도메인에서 중요하다.

insert + update 인 upsert 가 안티 패턴이라는 글도 많이 볼 수 있다. 처음엔 upsert 가 사용하기 편리하단 이유만으로 많이 애용했었는데, 애초에 동작하는 방식과 로직이 다르므로 별개의 케이스로 생각하는게 맞다. (사용자는 insert 만을 원했는데 db 에 해당 key 가 이미 존재한다는 이유로 원래 값을 덮어쓴다? 이건 이상한 것 같다.)

ex) 사용자는 key 가 1234 인 객체를 생성하고 싶다. 그런데 key 를 123 으로 잘못 입력해 upsert API 를 호출한다. 그럼 key 가 123 인 객체가 수정된다. (에러를 뱉는게 정상이겠지..)

[JasonYoo1995]

[ 불변식 (Invariant) 이란? - ChatGPT의 답변 ]

• 프로그램이 실행되는 동안 항상 유지되어야 하는 특정한 조건으로, 프로그램의 올바른 동작을 보장함
• 프로그래머는 적절한 검증 코드를 작성하여 불변식을 검사할 수 있음
• 프로그램의 유효성을 보장하며, 잘못된 값이나 부적절한 상태를 가진 객체가 사용되는 것을 방지
• 코드의 안정성과 신뢰성, 예측 가능성을 높일 수 있음
• 불변식은 프로그램의 성능을 향상시키기도 함 예를 들어, 불변 객체(Immutable Object)는 상태를 변경할 필요가 없으므로 캐싱에 이용될 수 있으며 이는 복잡한 계산을 반복하지 않아도 되기 때문에 성능상 이점을 가져올 수 있음
• 불변 객체를 사용하면, 멀티스레드 환경에서 안전하며, 디버깅과 유지보수가 쉬워짐

[ AGGREGATE ]

• 도메인의 특성과 요구사항에 따라 반드시 지켜져야 하는 불변식과 반드시 지켜질 필요가 없는 불변식이 있다
• 반드시 지켜져야 하는 불변식을 깨뜨리도록 AGGREGATE를 설계하면, 비즈니스 규칙을 어기게 되는 위험한 결과를 초래한다
• 반드시 지켜질 필요가 없는 불변식을 보장하도록 AGGREGATE를 설계하면, 경합으로 인한 성능 낭비가 발생한다
• 불변식을 지키는 선에서 변경의 빈도에 따라 AGGREGATE의 경계를 적절히 설계하면, 성능을 최적화할 수 있다
• AGGREGATE의 경계를 어떻게 설계했느냐에 따라, 클래스의 구성과 DB의 잠금 수준/범위가 달라진다
• P.139 : AGGREGATE는 생명주기의 전 단계에서 불변식이 유지돼야 할 범위를 표시해준다.
• 예시
  • 구매주문(Lock X) : 불변식 위반 (허용 금액 한도 초과)
  • 구매주문(Lock O) / 품목 (Lock O) : 성능 저하 및 데드락 발생
  • 가격(Lock X)을 별도의 AGGREGATE로 분리하고 불변 객체로 복사하여 사용 : 성능 개선 및 데드락 해소

[emiling]

불변식은 데이터가 변경될 때마다 유지되야 하는 일관성 규칙을 뜻하며, 여기엔 AGGREGATE 를 구성하는 각 구성요소 간의 관계도 포함 될 것이다.

저번주에 https://github.com/caffeine-library/Domain-Driven-Design/issues/12 이슈에서 다룬 정책 검증과 관련해서 생각해볼 수 있을 것 같네요. 이와 관련해서 조금 찾아보다가 아래 아티클을 읽고 간단히 정리해보았습니다.

https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-model-layer-validations

DDD에서 유효성 검사 규칙은 불변성(invariants) 으로 생각할 수 있습니다. AGGREGATE의 주요 책임은 해당 AGGREGATE 내의 모든 ENTITY에 대해 상태 변경에 걸쳐 불변성을 적용하는 것입니다.

유효성 검사는 일반적으로 도메인 ENTITY 생성자 또는 ENTITY를 업데이트 할 수 있는 메서드에서 구현됩니다. 유효성 검사를 구현하는 방법에는 다음과 같은 방법들이 있습니다.

• 데이터를 확인하고 유효성 검사에 실패할 경우 예외를 발생시킴
• Specification Pattern
• 각 유효성 검사가 발생할 때 마다 예외를 반환하는 대신 오류 모음을 반환하는 Notification pattern

도메인 모델 레이어에서 검증로직 구현하기

• Validate conditions and throw exceptions
  • 엔터티 생성자 및 setter에서 엔터티가 유효한지 확인하기 위한 예외 발생
• Use validation attributes in the model based on data annotations
  • (However, from a DDD point of view, the domain model is best kept lean)
• Validate entities by implementing the Specification pattern and the Notification pattern
• ...

[JasonYoo1995]

[1번째 커멘트 관련 논의 내용]

• Service가 도메인 객체 또는 Repository에서 Transaction을 거는 방법
• JPA에서 MongoDB로 교체한다면? 의존성 분리
  • Trade Off : 교체 대비 vs 생산성 저하
• RDB에서 조회한 Entity와 도메인 객체의 형태가 많이 다른 경우