💫 소프트웨어 아키텍처 with 도메인

아키텍처의 중요성?

아키텍처는 여러 이유들로 정답이 없다고 합니다.

• 원칙과 편의성에서 트레이드오프가 존재
• 아키텍처는 제약이며 언제든 바뀌는 것
• 아키텍처는 사람마다, 조직마다, 회사마다 생각이 다름
• 시스템 안정성과 추상화가 모두 1에 가까운 영역은 Zone of Exclusion (📖Clean Architecture에서)

이 글도

"헥사고날 아키텍처가 요즘 심심찮게 들리니 당장 도입해 봅시다!"

 와 같은 글이 아닌 도메인을 중요하게 여기는 개발과 아키텍처를 공부하며 얻은 느낀 점들을 공유하고자 글을 작성합니다.

• 도움받은 강의, 책 : 클린 아키텍처, 인프런 강의-Java/Spring 주니어 개발자를 위한 오답노트

🏗️ 소프트 아키텍처

도메인의 중요성

소프트웨어에서 도메인이란? 일반적으로 소프트웨어가 해결하려고 하는 문제 영역 또는 비즈니스 로직이 적용되는 특정 분야를 의미

 

아키텍처에 대한 얘기를 하기 전 도메인의 중요성을 얘기해 보고자 합니다.
소프트웨어 개발에서 도메인이 중요하다고 합니다.

• 도메인은 소프트웨어의 핵심이고 비즈니스 문제를 해결하는 객체
  • 도메인 지식은 문제를 깊이 이해하고, 이를 기반으로 효과적인 해결책을 설계하는 데 필수적
• 시스템의 모듈성 증가
  • 도메인 중심으로 시스템을 구성하면, 관련 기능과 데이터를 도메인 별로 그룹화
• 분리와 추상화의 중요성
  • 도메인 로직과 인프라스트럭처, UI 등을 명확하게 분리하여, 각각의 변경이 다른 부분에 미치는 영향을 최소화해야 함
  • 도메인 로직이 본질, 그 외는 언제든 변경될 수 있다.

이 외에도 여러 내용이 나오지만 직접 코드단에서 느꼈던 도메인의 장점을 설명해 보자면,

@Transactional
public void updateProductForSale(Long productId, int quantitySold, int discountRate) {
    // 데이터베이스에서 상품 조회 후 도메인 객체로 리턴
    Product product = productRepository.findById(productId);

    // 할인율 검증
    if (discountRate < 0) {
        throw new IllegalArgumentException("할인율은 0보다 커야 합니다.");
    }

    // 할인 가격 계산
    Long originalPrice = product.getPrice();
    double discount = originalPrice * (discountRate / 100.0);
    Long discountedPrice = originalPrice - (long) discount;

    // 재고 검증
    if (product.getStockQuantity() < quantitySold) {
        throw new IllegalArgumentException("판매량이 재고보다 많을 수 없습니다.");
    }

    // 재고 감소
    int newStockQuantity = product.getStockQuantity() - quantitySold;
    product.setStockQuantity(newStockQuantity);

    // 할인된 가격으로 업데이트
    product.setPrice(discountedPrice);

    // 데이터베이스에 변경 사항 저장
    productRepository.save(product);

    System.out.println("할인된 가격으로 판매 처리되었습니다: " + discountedPrice + "원");
}

이 코드 예제에서는 할인율 검증, 할인 가격 계산, 재고 검증 및 감소 등의 모든 로직이 서비스 계층 내에 구현되어 있습니다.
이처럼 서비스에 많은 도메인 관련 로직이 있는 경우를 fat service라고도 부르는데 다음과 같은 문제가 있습니다.

• 도메인이 눈에 안 들어옴
• Product 객체가 수동적이고 함수 위주로 돌아가는 절차 지향적인 코드가 나옴
• 코드의 복잡도가 증가하고 재사용성이 감소

이를 해결하기 위해 Product의 도메인 로직을 Product 코드에 위임해 보겠습니다.

public class Product {

    // 관련 필드, 생성자 등 생략, 도메인은 POJO 객체

    // 상품 가격에 따른 할인 가격 계산
    public Long calculateDiscountedPrice() {
        if (this.price <= 0 || this.discountRate < 0) {
            throw new IllegalArgumentException("가격과 할인율은 0보다 커야 합니다.");
        }
        double discount = this.price * (this.discountRate / 100.0);
        return this.price - (long) discount;
    }

    // 상품 판매로 인한 재고 감소 처리
    public void sellProduct(int quantitySold) {
        if (this.stockQuantity < quantitySold) {
            throw new IllegalArgumentException("판매량이 재고보다 많을 수 없습니다.");
        }
        this.stockQuantity -= quantitySold;
    }
}

@Transactional
public void updateProductForSale(Long productId, int quantitySold, int discountRate) {
    // 데이터베이스에서 상품 조회 후 도메인 객체로 리턴
    Product product = productRepository.findById(productId);

    // 할인율 업데이트
    product.setDiscountRate(discountRate);

    // 할인 가격 계산
    Long discountedPrice = product.calculateDiscountedPrice();

    // 판매 처리
    product.sellProduct(quantitySold);

    // 데이터베이스에 변경 사항 저장
    productRepository.save(product);

    // 할인 가격 계산 출력
    System.out.println("할인된 가격: " + discountedPrice + "원");
}

이렇게 Service가 하던 역할을 도메인에 위임하면 다음과 같은 장점이 있습니다.

• 실제 업무를 도메인 영역에서 하게 됨
  • 도메인 레이어는 객체지향스러운 객체들의 협력 공간이 됨(TDA(Tell, Don't Ask) 법칙 준수)
• 단순화된 서비스 계층
  • 비즈니스 로직을 도메인 모델 내부에 캡슐화함으로써, 서비스 계층은 도메인 객체의 메서드를 조합하는 역할에 집중

💡 TDA (Tell, Don't Ask) 법칙이란?
- TDA 법칙은 "묻지 말고 명령하라"는 원칙으로, 객체의 상태를 직접 조회하여 로직을 수행하기보다는, 해당 객체에게 원하는 동작을 수행하도록 요청
- 이 법칙의 핵심은 객체의 내부 상태에 대해 묻지 말고, 필요한 동작을 그 객체에게 맡기는 것
- 그렇게 할 시 객체의 캡슐화가 유지되고, 객체 간의 결합도가 낮아져서 시스템의 유연성과 유지보수성이 향상

public class ProductTest {

    @Test
    public void 할인된_가격_계산_유효한_입력_정확한_결과_반환() {
        // given
        Product product = new Product(10000L, 10);

        // when
        Long discountedPrice = product.calculateDiscountedPrice();

        // then
        assertEquals(9000L, discountedPrice);
    }

    @Test
    public void 할인된_가격_계산_할인율_음수_예외_발생() {
        // given
        Product product = new Product(10000L, -10);

        // when, then
        assertThrows(IllegalArgumentException.class, product::calculateDiscountedPrice);
    }
}

또한 이런식으로 도메인은 외부 의존성이 없기 때문에 Mockito 등을 사용하지 않고 도메인 로직 자체의 정확성을 확인하는 테스트 코드를 짤 수 있습니다.

• 도메인 로직이 모델 내부에 존재하기 때문에, 단위 테스트를 통해 도메인 로직을 독립적으로 검증하기가 더 용이

아키텍처 구조 바꿔보기

도메인의 중요성을 알았으니 이를 중심으로 아키텍처를 바꿔봅시다.

레이어드 아키텍처

일반적인 레이어드 아키텍처입니다.
구현하기 쉽다는 장점이 있지만 다음과 같은 단점이 있습니다.

1️⃣ 개발을 시작할 때 도메인 위주로 생각하여 설계할 수 없다.
   소프트웨어를 설계할 때 도메인과 도메인 사이의 관계 등의 유즈 케이스를 먼저 설계하는 게 중요합니다.
   (상품을 파는 애플리케이션이라면 상품 관련 가격 정책, 주문 방식, 상품 리뷰 댓글 관리 등...)
   위의 레이어드 아키텍처로 설계하다 보면 도메인이 아닌 다른 부분을 위주로 설계하게 될 확률이 큽니다.
    - 하향식(repository)으로 생각하면 DB 위주의 설계(디비는 어떤 것을 써야 할지, 스키마는 어떻게 짜야 할지)
    - 상향식(controller)으로 생각 시엔 REST냐 gRPC냐.. 등으로 설계를 시작

2️⃣ Controller가 Service를, Service가 Repostory를 의존
    이는 Repository의 변화가 Service와 Controller에 영향을 끼쳐 OCP를 위반할 수 있습니다.
    특히 DB 등이 변경될 때 (예를 들어 MySQl에서 MongoDB로 DB가 바뀜) 서비스 코드에도 큰 변화가 생깁니다.

도메인 레이어 추가

우선 위의 1번 문제를 해결하기 위해 위의 예제 코드처럼 도메인 레이어를 추가합니다.
도메인 위주의 설계와 앞서 말했던 도메인 로직을 도메인 계층에 위임하는 이점을 얻을 수 있습니다.

❗️의존성 역전

 

위의 2번 문제를 해결하기 위해 Controller는 Service 인터페이스를 의존, Service는 Repository 인터페이스를 의존하도록 수정합니다.
기존의 Service와 Repository는 각각 인터페이스를 구현하게 합니다.

이렇게 구조를 변경 시 의존성의 방향이 바뀌는데요! 이러한 경우를 의존성의 역전이라고 합니다.
이 의존성 역전으로 2번 문제를 해결하고 관심사를 분리, 고립을 시킬 수 있습니다.
또한 Service나 Repository를 의존하고 있는 객체의 테스트가 필요할 때 Fake 객체를 만들어 테스트를 할 수 있습니다.
(✋ 참고로 다른 개념이지만 약자가 같은 의존성 주입은 보통 DI(Dependency Injection), 의존성 역전은 DIP(Dependency Inversion)로 부르는 것 같습니다.)

도메인을 가운데로 그림을 바꾸기

이런 식으로 같은 아키텍처를 도메인이 가운데에 향하도록 그림을 바꿀 수 있습니다.

🌟 클린 아키텍처, 핵사고날 아키텍처

(이미지 출처 : https://reflectoring.io/spring-hexagonal)

핵사고날 아키텍처라고 검색하면 다음과 같은 그림이 나오는데요!

위의 그림이 결국 클린 아키텍처, 핵사고날 아키텍처와 같은 내용이라고 생각합니다.
부르는 용어들은 다릅니다.

핵사고날 아키텍처에선 인터페이스를 포트, 호출하는 객체, 구현 객체는 아답터라고 부릅니다.

• 의존성에 방향에 따라 인풋 아답터, 인풋 포트, 아웃풋 포트, 아웃풋 아답터라고 부릅니다.

클린 아키텍처에선 가장 중요한 도메인과 유즈케이스를 제외하곤 험블(humble)이라고 부릅니다.

• 핵사고날과 아키텍처와 비교하여 인풋 포트를 유즈케이스, 아웃풋 포트는 게이트웨이라고 부릅니다.

결론

내용이 길었지만 결론은 다음과 같습니다.

• 도메인의 중요성을 인식
  • 본질은 도메인, 도메인 외의 것들 (DB, 프레임워크, 언어 등)은 언제든 변할 수 있고 이에 대비할 수 있는 유연한 아키텍처가 필요
• 도메인 중심 설계를 통해 서비스 계층의 복잡도를 줄이고 유지 보수성과 테스트 용이성을 향상
• 의존성 역전을 적용하여 OCP 위반을 방지하는 아키텍처 전략을 구현