의존성을 이용해 설계 진화시키기

https://www.youtube.com/watch?v=dJ5C4qRqAgA 

 

 

💭 설계란 무엇인가요?

코드를 어떻게 배치할 것인가. 어떤 패키지에 어떤 객체를 넣을 것인가.

왜 그런걸 고민할까? 결국 설계를 하는 본질은 변경을 관리하는 것에 있다. 

 

변경의 전파는 의존성을 의미한다. 같이 변경되는 코드를 함께 넣어라 의존성을 바탕으로 설계하라.

B가 변경됬을 때, A가 영향을 받는다면 의존성(Dependency)이 있는 것이다.

 

📑 의존성의 종류

• 연관관계 Association (영구적)
• 의존관계 Dependency (일시적)
• 상속을 이용한 확장 Inheritance ( 상속, 자식 )
• 인터페이스를 통한 확장 Realization ( 실체화 )

간단하게, 내 Import 문에 다른 패키지가 있다면 의존성이 있는 것.

 

📑 좋은 의존성1 - 꼭 필요한게 아니라면 의존성을 없애버려라

 

📑 좋은 의존성2 - 양방향 의존성을 피하라

양방향으로 의존성을 가진다는 것

= 항상 A, B 양쪽을 서로 동기화 해주어야함. (성능이슈, 버그 발생 쉬움)

= 같은 클래스를 억지로 찢어서 사용한다는 말. A➡B, B➡A 뭐가 바뀌든 양쪽에 변경이 전파됨.

특히 패키지 사이에서는 양방향 의존성이 있으면 안된다.

사이클이 생긴다는 것 = 패키지로 쪼갤 필요가 전혀 없다는 말이다. 하나의 패키지로 합쳐라

 

📑 좋은 의존성3 - 다중성이 적은 방향을 선택하라.

예를 들어 객체와 리스트가 있을 때 [객체]를 의존성의 주인으로 설정해야한다.

리스트에 의존성이 있으면 리스트 안에 있는 모든 객체의 의존성을 관리해주어야 하기 때문. 다중성이 너무 크다. 

 

 

💭 직접 만들어보며 의존성 파헤치기

📑 예제 플로우

 

📑 Domain Concept - 가게 & 메뉴

가게에는 여러가지 메뉴들이 있다.

메뉴는 옵션 그룹을 가질 수 있다. (크기 선택, 사이드 추가, 음료 추가)

메뉴에는 옵션 그룹 있고 여러가지 옵션이 추가되고 삭제될 수 있다.

📑 Domain Concept - 주문

주문은 주문 아이템(항목)들을 가진다.

주문 아이템은 옵션 그룹을 가질 수 있다.

 

 

📑 Domain Object - 객체들의 관계

 

📑 해당 도메인 모델의 문제점

주문은 장바구니에 담긴다.

장바구니는 서버가 아닌, 클라이언트(앱)에 저장된다.

만약 사장님이 메뉴를 바꾸신다면? 재고가 떨어져 판매중지를 해버린다면? 장바구니에는 그게 반영 되지 않는다.

장바구니에 담긴 주문과 현재 메뉴가 같은 값인지 검증해야한다.

 

값이 같은지 비교하는 것과 함께 비즈니스 로직도 검증해야한다.

가게가 영업을 종료했거나, 최소주문금액같은 비즈니스 규칙들도 검증해야한다.

 

 

📑 협력 설계하기

(1) 주문을 요청하면 [주문]이 생성된다.

(2) [주문]은 가게에 영업여부와 최소주문금액을 확인한다.

(3) [주문 항목]에 메시지를 보내서 [메뉴]와 같은지 검증을 한다.

(4) [메뉴]에서 [주문 옵션그룹] 과 [옵션그룹]이 같은지 검증한다.

(5) [주문 옵션]과 [옵션]이 같은지 검증한다.

 

📑 클래스 설계하기 (Class Diagram)

개발자는 변경될 수 있는 모든 가능성을, 정적인 코드로 설계해야한다.

클래스 간의 관계를 맺고 협력 구조를 만들어야한다. 즉 의존성의 방향을 정해야한다.

DB는 방향성이 없다. 외래키로 이동가능하다 / 객체는 방향성이 필요하다. 다른 객체에 메시지를 보내야 한다.

데이터에 영향을 받지만, 탐색이 필요하다면 연관관계로 설정한다. (필요없다면 나중에 끊을 수 있음)

언제나 참조에는 이유가 있어야 한다. 런타임에 객체들이 어떻게 협력하는가?

Association

연관관계는 탐색가능성 (navigablilty)를 의미한다.

예) Order를 알면, OrderLineItem을 찾을 수 있어요.

두 객체 사이에 협력이 필요하고, 두 객체의 관계가 영구적이라면 연관(Association)을 사용한다.

연관관계는 다양한 방법으로 구현할 수 있다. 개념과 구현을 1:1로 매칭하지 말자.

 

📑 구현 시작

코드를 작성할 때, 구현 메서드를 먼저 완성하지 마라.

아래와 같이 고수준의 메시지를 정하고, 그 이후 메서드를 작성하라.

@Entity
@Table(name="ORDERS")
public class Order {
    // .. Order 관련 코드 생략 .. //
    
    public void place() {
        validate();
        ordered();
    }

    private void validate() {
        
    }

    private void ordered() {
        
    }
}

이후 연관관계를 맺고, 메서드를 작성한다. (validate)

@Entity
@Table(name="ORDERS")
@Getter
public class Order {
    // .. Order 관련 코드 생략 .. //
    
    @ManyToOne
    @JoinColumn(name="SHOP_ID")
    private Shop shop;

    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name="ORDER_ID")
    private List<OrderLineItem> orderLineItems = new ArrayList<>();
}

 

지금은 도메인 레이어를 설계중임을 잊지말자.

도메인의 개념이 아닌 DB나 Web 응답/요청도 필요하다. 하지만 Domain 레이어를 설계할 때는 필요없다.

Order 도메인의 전체 코드

 

package org.eternity.food.domain.order;

import lombok.Builder;
import lombok.Getter;
import org.eternity.food.domain.generic.money.Money;
import org.eternity.food.domain.shop.Shop;

import javax.persistence.*;
import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.List;

@Entity
@Table(name="ORDERS")
@Getter
public class Order {
    public enum OrderStatus { ORDERED, PAYED, DELIVERED }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name="ORDER_ID")
    private Long id;

    @Column(name="USER_ID")
    private Long userId;

    @ManyToOne
    @JoinColumn(name="SHOP_ID")
    private Shop shop;

    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name="ORDER_ID")
    private List<OrderLineItem> orderLineItems = new ArrayList<>();

    @Column(name="ORDERED_TIME")
    private LocalDateTime orderedTime;

    @Enumerated(EnumType.STRING)
    @Column(name="STATUS")
    private OrderStatus orderStatus;

    public Order(Long userId, Shop shop, List<OrderLineItem> items) {
        this(userId, shop, items, LocalDateTime.now(), null);
    }

    @Builder
    public Order(Long userId, Shop shop, List<OrderLineItem> items, LocalDateTime orderedTime, OrderStatus status) {
        this.userId = userId;
        this.shop = shop;
        this.orderedTime = orderedTime;
        this.orderStatus = status;
        this.orderLineItems.addAll(items);
    }

    Order() {
    }

    public void place() {
        validate();
        ordered();
    }

    private void validate() {
        if (orderLineItems.isEmpty()) {
            throw new IllegalStateException("주문 항목이 비어 있습니다.");
        }

        if (!shop.isOpen()) {
            throw new IllegalArgumentException("가게가 영업중이 아닙니다.");
        }

        if (!shop.isValidOrderAmount(calculateTotalPrice())) {
            throw new IllegalStateException(String.format("최소 주문 금액 %s 이상을 주문해주세요.", shop.getMinOrderAmount()));
        }

        for (OrderLineItem orderLineItem : orderLineItems) {
            orderLineItem.validate();
        }
    }

    private void ordered() {
        this.orderStatus = OrderStatus.ORDERED;
    }

    public void payed() {
        this.orderStatus = OrderStatus.PAYED;
    }

    public void delivered() {
        this.orderStatus = OrderStatus.DELIVERED;
        this.shop.billCommissionFee(calculateTotalPrice());
    }

    private Money calculateTotalPrice() {
        return Money.sum(orderLineItems, OrderLineItem::calculatePrice);
    }
}

 

💭 설계 개선하기

생각이 안나면 어쩔 수 없이 절차적(트랜잭션 스크립트)로 짤 수 밖에 없다.

그땐 변화의 방향. 의존성을 그려보자. 패키지 사이에 사이클이 도는가? 객체 참조가 결합도를 상승시키나?

하나씩 해결해나가며 객체지향적으로 개선해보자.

물론 이것 말고도 다양한 문제가 있으나, 하나씩 알아보자.

무슨 문제가 있을까? 자세히 보면, 사이클이 돌고 있다.

 

연관관계라고 하는 것은, 탐색 가능함을 의미한다.

이를 우린 객체 참조로 구현했었다. 연관관계를 설정했다.

메모리는 문제가 없다. DB에서 문제가 있다. LazyLoading을 어디까지 할 것인가?

어디까지 미리 읽어야해요? 객체가 다 연결되어있는데

무엇보다 트랜잭션 경계가 모호해진다.

어떤 테이블 까지 Lock을 걸어야 하는가?

연결 되어있는데.. 내가 수정한게 다른 곳에 영향을 끼치지않는다는 보장이 있을까?

예를 들어 배달완료에 트랜잭션 범위를 생각해보자.

하지만 잘 생각해보면, 각각의 도메인의 변경의 시점과 빈도가 다르다.

Long Transaction으로 묶어버리면 전체에 Lock이 걸려버린다. 모든 서비스가 중단된다.

 

📑 객체 참조가 꼭 필요할까?

객체 참조는 모든 것을 연결시켜버린다.

이는 긴 트랜잭션을 만들고, 객체간의 결합도를 높게 만든다.

점점 더 재사용과 수정이 어려워진다.

 

필요한 경우에는 객체 참조를 끊을 필요가 있다.

우린 탐색하기 위해 연관관계를 만들었고, 연관관계를 객체참조로 구현했다. 

이 결합도를 낮추기 위해 Repository라는 인터페이스(중간 객체)를 사용했다.

물론 비즈니스 로직이 아닌 조회성능을 따지기 시작하면.. 양방향 관계가 생긴다.

함께 생성되고, 함께 삭제된다면 같은 트랜잭션 단위로 묶어야한다. (대부분)

도메인 제약사항을 공유하는 객체들을 함께 묶어라.

 

근데 잘 생각해보면 당연한게 당연하지 않다. 비즈니스 규칙에 따라다르다.

일반적인 이커머스는 장바구니와 장바구니 항목사이 공유되는 제약사항이 없다.

[사용자가 만든 장바구니]와 [선택 가능한 장바구니 항목]은 생명주기가 완전히 다르다.

 

배달의 민족처럼, '장바구니에는 해당 가게의 물건만 넣을 수 있다'라는 도메인 제약사항이 있기에 묶은거지

만약 그런 규칙이 없다면? 이 두 객체는 함께 묶으면 안된다.

 

같이 생성되고, 같이 삭제되는건 연관관계로 묶는게 편하긴 하다. 크게 문제될 일도 없다.

이런 관계가 아니라면 연관관계로 (객체참조로) 사용하지 말고 ID를 통한 조회로 구현해서, 연관관계를 끊어버리자.

이를 트랜잭션 단위로 만들어버리면 된다. 조회도 마찬가지. 한번에 같이 or Lazy로딩

이는 DB 성능 튜닝에도 도움이 많이 된다.

어디까지를 읽어야할지에 대한 경계가 확실하기 때문이다. (order를 읽는데 Shop을 가져올 필요가 없다)

 

이렇게 단위를 나누면, 그룹단위로 저장소(영속성 저장소)를 변경할 수도 있다.

객체를 한방에 읽을 수 있다. = 트랜잭션의 단위 = 조회의 단위 (마치 DB의 한방쿼리처럼)

 

🧨 문제점1 - 컴파일이 안되요

왜? 우리는 객체참조를 이용해서 코드를 짰으니까.

참조값이 없으니 당연히 에러가 발생

 

해결책 : 한군데로 모으자

그리고 이 객체를 파라메타로 넘겨서 처리하도록 만들자.

 

 

기존 예제에서는 validate 로직을 탐색하기 매우 어려웠다. 

객체지향이 원래 그렇다. 협력을 이용하기 때문에 여러객체에 로직이 찢어져있다.

하지만 이렇게하면?

응집도 : 같이 변경되는 친구들이 한 곳에 모여있는가? (위 코드처럼 다른 변경주기가 섞여있다면 응집도가 낮음)

때로는 절차지향이 객체지향보다 좋습니다. 전체 플로우를 볼 수 있으니까.

객체의 결합도는 높이지만, 응집도도 함께 높일 수 있다. 이것도 트레이드 오프이다.

 

🧨 문제점2 - 아직도 컴파일이 안되요

객체에 변경사항을 전달해야하는데.. Id로만 가지고 있다.

도메인의 제약사항 특성상, Id로는 만들기가 어렵다. 변경사항이 전파되야하니

도메인 로직을 순차적으로 꼭 실행해야할까?

'이거 하자말자, 이걸 해주세요' ➡ 과연 이게 즉시일까? 예매 취소후, 바로 0.1초안에 환급을 해야할까?

물론 기존 방법처럼 절차지향으로 해결해도 되긴하다.

비즈니스 플로우가 한 눈에 보인다.

이렇게 해당 객체를 주자

 

근데 이 경우에는 다르다. 변경을 하는거라서 의존성을 그려보면 아래와 같이 사이클이 생긴다.

인터페이스를 사용해서 의존성의 역전 (DIP)가 필요하다

실제 실행하는 쪽을 Delivery로 바꾸자. 의존성을 한 방향으로 바꾸자.

 

여기서 한번 정리하고 가자.

패키지 의존성을 해결하는 방법은 1. 중간객체를 만들거나. 2. 의존성을 역전시키는 것이다.

 

📑 다시 도메인 이벤트로

이제 도메인 이벤트로 해결하는 방법을 알아보자.

순서를 느슨하게 만들자. 상태의 변경을 이벤트로 처리하자. (메시지와는 상관X, 메모리상)

동기, 비동기, 같은트랜잭션, 다른트랜잭션 모두 구현가능

 

SpringAbstractAggregate는 편의 기능일 뿐, 사용하지 않아도 구현 가능하다. (DB 커밋할 때 이벤트 발행처리)

 

 

님!! 패키지에 의존성 싸이클이 도는데요!!

사이클을 또 해결을 해야한다. 중간 객체나 DIP를 통해서 (인터페이스와 Impl 분리)

근데 Event에서는 3번째 방법이 있다. EventHandler를 다른 패키지로 분리해버리는 것.

 

패키지를 찢을 때에는, 도메인적으로 새로운 개념이 필요하다. (정산이라는 개념의 추가)

 

💭 최종 정리. 패키지 의존성을 끊는 방법

결국 중요한건 변경에 유연한 서비스를 만드는 것이다.

변경에 유연하려면 변경의 전파를 막아야한다. 의존성을 관리해야한다.

즉 도메인(패키지)간의 의존성을 최대한 끊어야 한다. 사이클을 제거해야한다.

프로젝트를 레이어 단위(Service Domain..)로 관리하면 도메인을 분리하기가 어렵다.

이를 이렇게 만드는 것. 시스템을 분리하기 편하게

프로젝트를 도메인 단위로 구현하는게 좋다. (그 안에 레이어를 구성)

 

 

방법은 정하기 나름이고, 각각 트레이드 오프가 존재한다. 많이 이용하는 방법은 총 3가지이다.

1. 중간 객체를 만들어서 의존성 제거

2. DIP를 이용해서, 인터페이스(또는 추상클래스)를 의존하도록 변경한다.

3. 도메인 개념을 추가해서 패키지를 찢어버린다.

 

----------

결국 최종적으로는, 내부 이벤트 -> 외부이벤트의 전달을 통한 System Event 개념을 만들어서 MSA를 구현함.

시스템을 마이크로서비스로 쪼개고 부하를 줄인다.