트랜젝션 스크립트 패턴
서비스 계층에서 직접 DB에 붙어서 비즈니스 로직을 처리하는 것.
- 비즈니스 로직이 복잡할수록 트랜젝션 간에 비즈니스 로직이 중복되기 쉽다.
- 중복된 코드가 동기와 되지 않으면 일관성 없는 동작이 발생하기 쉽다.
- 그로 인해 유지보구사 어려운 거대한 진흙 덩이가 될 가능성이 큼
액티브 레코드 패턴
객체 모델(Entity)을 만들어서 사용.
끽해봐야 getter
, setter
정도이며 save() 정도
정의.
도메인 모델
액티브 레코드와 다르게 비즈니스 로직을 모델에 위임.
/*액티브 래코드*/
public void service(){
User user = new User();
user.setEmail("배고파@naver.com")
}
public class User{
private String name;
private String email;
// getter, setter ...
}
액티브 레코드는 단순 getter
, setter
정도만 사용하였기에
서비스 단에서 email을 세팅할 때 이메일 규칙을 검사하지 않고 세팅하거나 매번 세팅할 때마다 이메일 검사 규칙을 따로 만들어서 사용해야 함.
반면 도메인 모델은
public void service(){
User user = new User();
user.addEmail("배고파@naver.com")
}
public class User{
private String name;
private String email;
// setter 사용X 혹은 사용하더라도 적근제한 걸어두기
public boolean addEmail(String email){
// 이메일 규칙 검사 로직
}
}
이렇게 사용함으로써 로직 중복도 제거하고 사용가능
하지만 도메인 모델도 거대한 진흙 덩이가 될 수 있음.
엔티티에 계속 물리고 물리면서 거대해질 수 있기 때문.
메인 모델링 거대해지면 메모리에 엄청 큰 데이터가 로딩되어 문제가 생길 수 있다.
마틴 파울러는 이 도메인 모델을 이야기하면서 에릭 에반스가 도메인 모델을 더 잘 사용할 수 있도록 하는 책을 쓰고 있다며 소개해줌. 그게 DDD의 애그리 거트이다.
애그리거트
애그리거트는 도메인모델을 바운디드 컨택스트처럼 관리할 단위를 구분지어서 작성한다.
트렌잭션 단위로 집합을 나누고 최상위 엔티티를 애그리거트 루트라고 부른다.
참조 관계로 엔티티나 VO를 이어나갈 수 있다.
VO랑 DTO랑 명확히 구분해줘야 함.
여기서 쓰이는 VO는
- 불변이 여야함
- 수정이 아니고 수정할 일이 있으면 전체를 교체해줘야 함. (마치 String처럼..)
- 고유 식별자가 없어야 함.
를 지켜야 한다.
모든 애그리거트에 대한 접근은 애그리거트 루트를 통해서만 할 수 있어야 한다.
애그리거트의 모든 요소는 반드시 비즈니스 규칙을 따라야 하며 일관성을 유지해야 한다.
보통 애그리거트 하나에 하나의 엔티티인 경우가 대부분이다.
애그리거스 설계 시 4가지 기본규칙
애그리거트 결재 내에서 비즈니스 불변사항을 보호해라(setter 사용금지)
작은 애그리거트를 설계해라
오직 ID를 통해서 다른 애그리거트를 참조해라
- 직접 참조하면 하나의 트랜잭션 내에서 여러 개의 애그리거트가 수정되는 일이 발생한다.
결과적 일관성을 사용해 다른 애그리거트를 갱신해라
- 결과적 일관성 : 잠깐동안 일관성을 잃더라도 결과적으로는 일관성을 유지해야 한다.
'Aarchitecture > Domain Driven Design' 카테고리의 다른 글
비동기 이벤트 (0) | 2023.01.27 |
---|---|
이벤트 (0) | 2023.01.26 |
Layered Archiecture (0) | 2023.01.25 |
바운디드 컨텍스트 (0) | 2022.12.21 |
도메인 주도 설계란? (0) | 2022.12.20 |