Tech Log 🛠️

애그리거트와 트랜잭션

애그리거트에 대해 사용할 수 있는 대표적인 트랜잭션 처리 방식

1. 선점 잠금

2. 비선점 잠금

선점 잠금

애그리거트 사용이 끝날 때까지 다른 스레드가 헤딩 애그리거트를 수정하지 못한다.

ex) agg1이 수정하는 동안 agg2는 잠금이 해제될 때까지 블로킹된다.

선점 잠금 방식을 사용하면 데이터 충돌 문제를 해소할 수 있다.

하지만 교착 상태에 빠질 수 있다.

교착 상태란?

스레드가 각자 다른 애그리거트를 선점하다가 서로의 애그리거트에 접근하는 경우

교착 상태에 바지면 시스템은 마비되며, 사용자가 많을 수록 발생하기 쉽다.

최대 대기 시간을 설정해줌으로써 교착 상태를 해결할 수 있다.

비선점 잠금

변경한 데이터를 실제 DBMS에 반영하는 시점에 변경 가능 여부를 확인

-> 버전 값을 사용한다.

만약 커밋 시에 애그리거트 버전이 다르면 데이터 수정에 실패한다.

하지만 루트 애그리거트 외 다른 엔티티가 변경 되었을 경우, 버전이 그대로인 것을 막기 위해 강제로 버전을 증가시킬수 있다.

오프라인 선점 잠금

여러 트랜잭션에 걸쳐 동시 변경을 막는다.

첫 번째 트랜잭션에서 오프라인 잠금을 선점하고 , 마지막에 잠금을 해제한다.

만약 오프라인 선점 잠금을 하고 해제하지 않는 경우를 대비하기 위해 잠금 유효 시간을 설정해야한다.

필요에 따라서 연장할 수 있다.

도메인 모델과 경계

한 개의 모델로 여러 하위 도메인을 모두 표현하려고 하면 맞지 않는 모델을 만들게 된다.

ex) 카탈로그에서의 상품과 재고 관리에서의 상품은 다른 의미이다.

모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다.

그러므로 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야한다.

바운디드 컨텍스트

모델의 경계를 결정하며 논리적으로 한 개의 모델을 갖는다.

실제로 사용자에게 기능을 제공하는 물리적 시스템으로 도메인을 구현한다.

만약 하나의 바운디드 컨텍스트에서 개발할 때는 하위 도메인 모델이 섞이지않도록 해야한다.

바운디드 컨텍스트 구현

바운디드 컨텍스트는 표현 영역 , 응용 서비스 , 인프라를 모두 포함한다.

복잡한 로직을 갖지 않는다면 CRUD 로 구현해도 상관없다.

두 가지 방식을 혼합해서 사용할 수도 있다.

-> CQRS 상태를 변경하는 기능과 쿼리 기능을 구분

도메인 서비스

여러 애그리거트가 필요하고 책임이 애매할 때 도메인 서비스를 이용할 수 있다.

도메인 서비는 다음 상황에 이용된다.

1. 계산로직

2. 외부 시스템 연동이 필요한 로직

도메인 서비스는 상태 없이 로직만 구현한다.

도메인 서비스를 애그리거트 객체에 주입하면 안된다!

외부 시스템 연동과 도메인 서비스

public interface API {
	...
}

도메인 로직 관점에서 인터페이스를 작성해야한다.

응용 서비스는 이 도메인 서비스를 이용해서 기능을 수행한다.

도메인 서비스의 로직이 고정되어 있지 않으면 , 도메인 서비스 자체를 인터페이스로 구현할 수 있다.

도메인 서비스의 구현이 특정 기술에 의존하거나 외부 API를 사용한다면 추상화해야한다.

표현 영역과 응용 영역

응용 영역과 표현 영역은 사용자와 도메인을 연결해주는 매개체 역할이다.

표현 영역은 사용자의 요청을 해석하고 그 기능을 제공하는 응용 서비스를 실행한다.

응용 영역은 실제 사용자가 원하는 기능을 제공한다.

두 영역은 서로 요구하는 파라미터와 형식이 다르기 때문에 요청을 변환해야한다.

사용자가 상호작용은 표현 영역이 처리하기 때문에, 응용 서비스는 표현 영역에 의존하지 않아야한다.

응용 서비스의 역할

사용자의 요청을 처리하기 위해 리포지터리에서 도메인 객체를 가져와 사용한다.

public Result func(Req req){
	// 리포지터리에서 애그리거트를 구함
	Agg agg = AggRepository.finById(req.getId());
    
    // 애그거트의 도메인 기능 실행
    add.doFunc(req.getValue());
    
    // 결과 리턴
    return createSuccessResult(agg)

}

도메인 로직을 도메인 영역과 응용 서비스에 분산해서 구현하면 여러 문제가 발생한다.

1. 코드의 응집성이 떨어진다.

2. 동일한 도메인 로직을 구현할 가능성이 높아진다.

응용 서비스를 구현할 때 몇가지 고려할 사항이 있다.

1. 응용 서비스의 크기

도메인과 관련된 기능을 한 서비스에 넣는다면 클래스가 커지고 관련없는 코드가 뒤섞일 수 있다.

한 응용 클래스에서 한개 내지 2~3개의 기능을 구현하면서 서비스 클래스를 구현하자

2. 인터페이스가 필요한 지

구현 클래스가 여러 개가 아닌 경우, 인터페이스는 불필요하다.

응용 서비스에서 애그리거트 자체를 리턴하면 도메인 로직을 여러 곳에서 실행할 수 있게된다.

따라서 응용 서비스에서는 필요한 데이터만 리턴하는 것이 응집도를 높이는 방법이다.

응용 서비스의 구현

응용 서비스는 표현 영역에 의존하지 않아야한다.

그 이유는 

1. 응용 서비스만 단독으로 테스트하기 어려워진다.

2. 표현 영역의 역할까지 대신하게 된다.

표현 영역의 상태를 응용 서비스에서 변경해버리면 로직을 추적하기 어려워진다. -> 유지보수 비용 증가

이를 위해서 서비스 메서드의 파라미터와 리턴 타입이 표현 영역의 구현 기술을 사용하지 않는 것이다.

표현 영역

1. 사용자가 시스템을 사용할 수 있도록 알맞은 흐름을 제공한다.

2. 사용자의 요청에 맞게 응용 서비스에 기능 실행을 요청한다.

3. 응용 서비스의 실행 결과를 알맞은 형식으로 제공한다.

4. 사용자 세션을 관리한다.

값 검증

원칙적으로 모든 검증은 응용 서비스에서 처리한다.

하지만 각각의 예외를 따로 던질 경우, 사용자는 하나의 이유만 확인할 수 있다.

따라서에러 코드를 모아 하나의 예외로 던질 수도 있다.

표현 영역에서 필수 값과 형식을 검사하면 응용서비스에서는 논리적 오류만 검사하면 된다.

조회 전용 기능과 응용 서비스

응용 서비스가 사용자 요청 기능을 실행하는 데 별다른 기여를 하지 못한다면 굳이 서비스를 만들지 않아도 된다.

애그리거트

객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.

-> 상위 수준에서 모델을 조망해야하는데 , 애그리거트를 사용할 수 있다.

애그리리거트는 복잡한 도메인을 단순한 구조로 만들어준다.

애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 가지며 다른 애그리커트에 속한 객체는 다른 애그리커트에

속하지 않는다.

애그리거트 루트

애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 루트 엔티티이다.

ex) Order -> (OrderLine) , (Orderer) , (Address)

핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.

루트는 애그리거트가 제공해야할 도메인을 구현한다.

애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다.

Info info = order.info();
info.setAddress(newAddress);

도메인 모델에 대해 다음 두가지를 지켜야한다.

1. 단순한 set 메소드를 공개 범위로 만들지 않는다.

2. 밸류 타입은 불변으로 한다.

잠금 대상이 많아진다는 것은 그만틈 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것이다. 

-> 성능의 저하

한 트랜잭션 내에서는 한 개의 애그리거트만 수정해야한다.

한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

리포지터리와 애그리거트

객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.

애그리거트 전체를 저장소에 영속화해야한다.

ID를 이용한 애그리거트 참조

애그리거트에서 다른 애그리거트를 참조한다는 것은 애그리거트의 뤁트를 참조한다는 것과 같다.

애그리거트를 직접 참조할 때 가장 큰 문제는 편리함을 오용할 수 있다는 것이다.

-> ID를 사용해서 다른 애그리거트를 참조하자

ID를 사용해서 참조하면 모든 객체가 참조로 연결되자 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.

애그리거트를 팩토리로 사용하기

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 다른 애그리거트에 팩토리 메소드를 구현하는 것을 고려해보자

네 개의 영역

표현 영역

HTTP 요청을 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 다시 응답을 HTTP 응답으로 변환하여 전송

ex) mvc 프레임워크

응용 영역(서비스 계층)

도메인 영역의 모델을 사용해서 사용자에게 제공하는 기능을 구현한다.

로직을 직접 수행하기 보단 도메인 모델에 로직 수행을 위힘

도메인 영역

도메인 모델을 구현하고 핵심 로직을 구현

public cancelOrder(String orderId) {
	Order order = findOrderById(orderId); // 도메인 모델에 위임
    ...
}

인프라 스트럭쳐 영역

논리적 개념 보다는 구현 기술을 다룬다.

ex) DB ,SMTP , 카프카

계층 구조 아키텍처

아키텍처는 보통

표현 -> 응용 -> 도메인 -> 인프라스트럭쳐 로 이루어져있다.

상위 계층은 하위 계층에 의존할 수 있지만 그 반대는 존재하지 않는다.

꼭 바로 아래 계층에만 의존하지 않고 유연적으로 의존성을 가져가기도 한다.

ex) 응용 -> 인프라

하지만 이 경우 두 가지 문제가 생긴다

1. 구현 설정을 모두 끝내야하기 때문에 테스트가 어려움 

2. 구현 방식을 변경하기 어려움

따라서 DIP를 적용하면 위의 문제를 해결할 수 있다.

DIP

고수준 모듈

- 의미 있는 단일 기능을 제공하는 모듈

- 여러가지 하위 기능이 필요하다

저수준 모듈

- 고수준 모듈의 하위 기능을 구현 

ex) JPA , Drools

고수준 모듈이 저수준 모듈에 의존하면 앞서 말한 두가지 문제가 생긴다.

그래서 DIP는 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다.

이때 추상화한 인터페이스를 사용한다.

인터페이스를 통해 더 이상 고수준 모듈이 저수준 모듈에 의존하지 않는다.

이를 의존 관계 역전(DIP)라고 한다.

DIP를 통해 두 가지 문제를 해결할 수 있다.

1. 기술 교체를 쉽게 할 수 있다.

// 사용할 저수준 객체 생성
Rule Discounter ruleDiscounter = new DroolsRuleDiscounter();

// 생성자 방식으로 주입
CalculateDiscountService disService = new CalculateDiscountService(ruleDiscounter);

2. 테스트가 용이하다.

기존에는 기술이 구현되어야 할 수 있었지만 이젠 대역객체(mock)을 이용해서 간편하게 진행할수 있다.

스텁이나 모의 객체와 같은 테스트 목적의 대역을 사용하여 거의 모든 상황을 테스트할 수 있다 !

* 인터페이스를 설계할 때 저수준 모듈에서 추출하지 않아야한다 !!

* 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출한다 !!

도메인 영역의 주요 구성요소

엔티티

- 고유의 식별자를 가지고 도메인의 고유한 개념을 표현한다.

밸류

- 개념적으로 하나인 값을 표현

ex) 주소 , 금액

애그리거트

- 연관된 엔티티와 밸류 객체를 개념적으로 묶은 것

리포지터리

- 도메인 모델의 영속성을 처리한다.

도메인 서비스

- 특정 엔티티에 속하지 않은 도메인 로직

- 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

도메인 엔티티 VS DB 엔티티

도메인 엔티티

- 데이터와 함께 도메인 기능을 제공한다.

- 도메인 관점에서 기능을 구현하고 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.

- 개념적으로 하나인 경우 밸루 타입을 이용해서 표현할 수 있다.

애그리거트

- 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데

도움이 된다.

- 관련 객체를  하나로 묶은 군집

- 객체 군집 단위로 모델을 바라본다.

- 루트 엔티티는 에그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 구현해야할 기능을 제공한다.

- 루트 엔티티를 통해 다른 엔티티나 밸류 객체에 접근한다.-> 캡슐화

리포지터리

- 애그리거트 단위로 객체를 저장하고 조회하는 기능을 정의한다.

- 도메인 모델을 사용해야 하는 코드는 리포지터리를 통해 도메인 객체를 구한 뒤에 도메인 객체의 기능을 사용

요구 사항

요구사항을 올바르게 이해하지 못하면 엉뚱한 기능을 만들게 된다.

(Garbage in , Garbage out)

-> 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요하다 !

도메인 모델

특정 도메인을 개념적으로 표현한 것을 도메인 모델이라고 한다.

도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 이해할 수 있으며, 여러가지 종류로 모델링 할 수 있다.

ex) 객체 , 상태 다이어그램, 그래프

도메인 모델 패턴

도메인 계층은 도메인의 핵심 규칙을 구현한다.

아래의 코드는 주문 상태에 따라 배송지를 변경할 수 있는 가에 대한 코드를 도메인 모델 패턴으로 구현

public class Order {
	private OrderState state;
    private ShippingInfo info;
    
    public void changeShippingInfo(ShippingInfo info) {
    	if(!state.isShippingChangeable()) {
        	// 예외처리
        }
        ...
    }
    ...
}

public enum OrderState {
	PAYMENT_WAITING {
    	public boolean isShippingChangeable() {
        	return true;
        }
    }
    ...
}

혹은 이렇게도 구현할 수 있다.

public class Order {
	private OrderState state;
    private ShippingInfo info;
    
    public void changeShippingInfo(ShippingInfo info) {
    	if(!state.isShippingChangeable()) {
        	// 예외처리
        }
        ...
    }
    
	private boolean isShippingChangeable() {
    	return state == OrderState.PAYMENT_WAITING || ...
    }
    ...
}

public enum OrderState {
	PAYMENT_WAITING
    ...
    ;
    
}

중요한 점은 Order , OrderState 같은 주문 도메인 모델에 구현 했다는 점이다.

이렇게 함으로써 요구사항이 변경되더라도 다른 코드에 영향을 덜 줄 수 있다.

도메인 모델 도출

구현을 시작하려면 도메인에 대한 초기 모델이 필요하다.

몇가지 요구사항으로 부터 구현해야할 기능과 데이터를 알 수 있다.

ex)

최소 한 종류 이상의 상품 주문 -> 로직 구현 필요

한 상품을 한 개 이상 주문할 수 있다. -> 구매 상품 정보는 상품 개수를 포함한다

엔티티

엔티티의 가장 큰 특징은 식별자를 가지는 것이다.

식별자는 엔티티가 생성되고 속성을 바꾸고 삭제할 때까지 바뀌지 않는다.

즉 식별자가 같으면 같은 엔티티이다.

식별자는 사용하는 도메인의 특징과 사용하는 기술에 따라 달라지며, DB에서 생성해주기도 한다.

(이 경우 DB에 저장해야 알 수 있음)

밸루(value) 타입 

개념적으로 완전한 하나를 표현할 때 밸루 타입을 사용할 수 있다.

private String receiverName;
private String receiverPhoneNumber;

//다음과 같이 표현 가능
private Receiver receiver;

무조건 두 개 이상의 필드를 가져야 하는 것은 아니다.

public class Money {
	private int value;
    
    public Money(int value) {
    	this.value = value;
    }
}

다음과 같이 정수형의 value를 Money 로 표현함으로써 의미를 명확하게 할 수 있다.

또한 해당 클래스 내에 더하기 , 곱하기 같은 비즈니스 로직을 추가할 수 있다.

밸루 타입은 안전한 코드 작성을 위해 불변으로 표현한다.

*불변 : 데이터 변경 기능을 제공하지 않음

도메인 모델이 set 메소드를 넣지 않는 이유

1. 핵심 개념이나 의도를 코드에서 사라지게 한다.

// 도메인과 의도가 명확함
public void completePayment();

// 필드값만 변경하고 끝, 의도가 명확하지 않음
pubic void setStatus();

2. 도메인 객체를 생성할 때 온전하지 않는 상태가 될 수 있다.

Order order = new Order();

// set 메소드로 값을 전달
order.setOrderLines(lines);

만일 위와 같이 set 메소드로 값을 전달한다면 나중에 필드가 null인지 검사하는 코드가 필요하다.

하지만 생성할 때부터 모든 데이터를 받는다면 생성하는 시점에 검사하면 되므로 해당 로직이 필요가 없어진다.

도메인 용어와 유비쿼터스 언어

도메인 용어를 코드에 반영하지 않는다면 해석하는데 부담이 된다.

// 도메인 용어가 반영되지 않음
public OrderState {
	STEP1,STEP2,STEP3,STEP4;
}

// 도메인 용어가 반영되서 직관적임
public OrderState {
	PAYMENT_WAITING,PREPARING,SHIPPED,DELIVERING;
}

도메인 용어에 알맞은 단어를 찾는 시간을 아까워하지 말자!