Skip to content
woojin.jang edited this page Jul 17, 2026 · 1 revision
  • 애플리케이션의 아키텍처를 테스트할 수 있는 오픈소스 라이브러리로 패키지, 클래스, 레이어, 슬라이스 간의 의존성을 확인할 수 있는 기능을 제공한다.
  • 아키텍처 테스트 유스 케이스
    • A라는 패키지가 B(또는 C, D) 패키지에서만 사용되고 있는지 확인할 수 있다.
    • "Service"라는 이름의 클래스들이 "Controller" 또는 "Service"라는 이름의 클래스에서만 참조하고 있는지 확인할 수 있다.
    • "Service"라는 이름의 클래스들이 ..service..라는 패키지에 들어있는지 확인할 수 있다.
    • A라는 어노테이션을 선언한 메서드만 특정 패키지 또는 특정 어노테이션을 가진 클래스를 호출하고 있는지 확인할 수 있다.
    • 특정한 스타일의 아키텍처를 준수하고 있는지 확인할 수 있다.

ArchUnit 아키텍처 규칙 검증

<!-- Source: https://mvnrepository.com/artifact/com.tngtech.archunit/archunit-junit5 -->
<dependency>
    <groupId>com.tngtech.archunit</groupId>
    <artifactId>archunit-junit5</artifactId>
    <version>1.4.2</version>
    <scope>test</scope>
</dependency>
  • 특정 패키지에 해당하는 클래스를 바이트 코드를 통해 읽어들여 확인할 규칙을 정의. 읽어들인 클래스들이 그 규칙을 잘 따르는지 확인한다.
  1. 패키지 의존성 검증
// ⭕ Good(레이어드 아키텍처 검증 - 계층 간 의존 방향 강제)
import com.tngtech.archunit.core.importer.ClassFileImporter;
import com.tngtech.archunit.lang.syntax.ArchRuleDefinition;
import com.tngtech.archunit.library.Architectures;
import org.junit.jupiter.api.Test;

import static com.tngtech.archunit.library.Architectures.layeredArchitecture;

class LayeredArchitectureTest {

    private final JavaClasses classes = new ClassFileImporter()
            .importPackages("com.example.myapp");

    @Test
    void 계층_간_의존_방향을_지킨다() {
        layeredArchitecture()
                .consideringAllDependencies()
                .layer("Controller").definedBy("..controller..")
                .layer("Service").definedBy("..service..")
                .layer("Repository").definedBy("..repository..")
                .layer("Entity").definedBy("..entity..")

                .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
                .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
                .whereLayer("Repository").mayOnlyBeAccessedByLayers("Service")
                .whereLayer("Entity").mayOnlyBeAccessedByLayers("Service", "Repository")

                .check(classes);
    }
}
// ⭕ Good(특정 패키지 의존성 감지 - domain이 infrastructure를 참조하면 안 된다.)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;

@Test
void domain_패키지는_infrastructure에_의존하지_않는다() {
    noClasses()
            .that().resideInAPackage("..domain..")
            .should().dependOnClassesThat().resideInAPackage("..infrastructure..")
            .check(classes);
}
// ⭕ Good(순환 참조 검증)
import static com.tngtech.archunit.library.dependencies.SlicesRuleDefinition.slices;

@Test
void 패키지_간_순환_참조가_없어야_한다() {
    slices()
            .matching("com.example.myapp.(*)..")
            .should().beFreeOfCycles()
            .check(classes);
}
  1. 네이밍/컨벤션 검증
// ⭕ Good(네이밍 컨벤션 강제)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

@Test
void Repository로_끝나는_클래스는_인터페이스여야_한다() {
    classes()
            .that().haveSimpleNameEndingWith("Repository")
            .should().beInterfaces()
            .check(classes);
}

@Test
void Service_클래스는_Service_어노테이션이_붙어야_한다() {
    classes()
            .that().resideInAPackage("..service..")
            .and().areNotInterfaces()
            .should().beAnnotatedWith(org.springframework.stereotype.Service.class)
            .check(classes);
}
// ⭕ Good(필드 주입 금지 - 생성자 주입 강제)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noFields;

@Test
void Autowired_필드_주입을_금지한다() {
    noFields()
            .should().beAnnotatedWith(org.springframework.beans.factory.annotation.Autowired.class)
            .check(classes);
}
// ⭕ Good(DTO는 도메인 로직을 가지면 안 된다)
@Test
void DTO는_public_메서드를_최소화한다() {
    classes()
            .that().haveSimpleNameEndingWith("Dto")
            .should().onlyHaveDependentClassesThat().resideInAnyPackage("..controller..", "..service..")
            .check(classes);
}

ArchUnit으로 클래스 의존성 확인

// ⭕ Good(특정 클래스가 다른 특정 클래스에 의존하면 안 된다)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;

@Test
void OrderService는_PaymentGateway를_직접_의존하지_않는다() {
    noClasses()
            .that().areAssignableTo(OrderService.class)
            .should().dependOnClassesThat().areAssignableTo(PaymentGateway.class)
            .check(classes);
}
// ⭕ Good(특정 클래스는 지정된 클래스에게만 접근을 허용한다 - 캡슐화 강제)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

@Test
void InternalOrderProcessor는_OrderFacade에서만_접근한다() {
    classes()
            .that().haveSimpleName("InternalOrderProcessor")
            .should().onlyBeAccessed().byClassesThat()
            .haveSimpleName("OrderFacade")
            .check(classes);
}
// ⭕ Good(특정 클래스는 지정한 클래스만 의존해야 한다 - 화이트리스트 방식)
@Test
void PaymentValidator는_허용된_클래스만_의존한다() {
    classes()
            .that().haveSimpleName("PaymentValidator")
            .should().onlyDependOnClassesThat()
            .resideInAnyPackage("java..", "..payment.validation..", "..payment.exception..")
            .check(classes);
}
// ⭕ Good(양방향 의존 금지 - A가 B를 의존하면 B는 A를 의존하면 안 된다)
@Test
void OrderService와_InventoryService는_서로_의존하지_않는다() {
    noClasses()
            .that().haveSimpleName("OrderService")
            .should().dependOnClassesThat().haveSimpleName("InventoryService")
            .andShould().onlyBeAccessed().byAnyPackage("..order..")
            .check(classes);

    noClasses()
            .that().haveSimpleName("InventoryService")
            .should().dependOnClassesThat().haveSimpleName("OrderService")
            .check(classes);
}
// ⭕ Good(구체 클래스가 아닌 인터페이스에만 의존해야 한다 - DIP 강제)
@Test
void Service는_Repository_구현체가_아닌_인터페이스에_의존한다() {
    noClasses()
            .that().resideInAPackage("..service..")
            .should().dependOnClassesThat()
            .haveNameMatching(".*RepositoryImpl")
            .check(classes);
}
// ⭕ Good(특정 클래스가 필드를 통해 직접 접근되는 것을 금지 - getter 강제)
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;

@Test
void Order_필드에_외부에서_직접_접근하지_않는다() {
    noClasses()
            .that().resideOutsideOfPackage("..order..")
            .should().accessFieldWhere(field -> field.getOwner().isEquivalentTo(Order.class))
            .check(classes);
}
  • 클래스 단위 규칙은 특정 도메인 객체의 캡슐화(예: Order 필드 직접 접근 금지)나 핵심 클래스 간 결합도 제한(예: 서비스 간 순환 의존 금지)처럼, 패키지 단위로는 표현하기 어려운 세밀한 제약을 걸 때 유용하다.

📖 Code Philosophy

📖 Java

📖 Kotlin

📖 Coroutine

📖 Spring

📖 Spring Security

📖 Spring Batch

📖 Database

📖 MySQL

📖 Redis

📖 JPA

📖 QueryDsl

📖 MSA

📖 Kafka

📖 Apache Flink

  • [Apache Flink - Apache Flink Architecture]
  • [Apache Flink - Stream Processing]
  • [Apache Flink - Data Stream API & Window]
  • [Apache Flink - State Management]

📖 HTTP

📖 AWS

📖 Docker

📖 Kubernetes

📖 Github Actions

📖 Jenkins

📖 Nginx

📖 Monitoring

📖 Test(feat. Load Testing)

  • [Test - Load Testing Fundamentals]
  • [Test - Identifying Bottlenecks with Load Testing]
  • [Test - Resolving Bottlenecks and Improving Performance]

📖 Test(feat. Java)

📖 Spring AI

📖 gRPC

  • [gRPC - Writing .proto Files with Protocol Buffers]
  • [gRPC - Various Communication Patterns in gRPC]
  • [gRPC - gRPC Optimization Techniques and Advanced Features]

📖 TDD(Test-Driven-Development)

📖 PostgreSQL

  • [PostgreSQL - Docker만을 사용하는 경량화된 환경 구성 방법]
  • [PostgreSQL - PostgreSQL에서 제공하는 데이터 타입]
  • [PostgreSQL - PostgreSQI의 JSONB, 역인덱싱과 활용 방법]
  • [PostgreSQL - 데이터베이스 성능을 위한 최적화 패턴 및 전략]
  • [PostgreSQL - 트랜잭션과 ACID, Isolation 수준별 차이]
  • [PostgreSQL - Database Lock 교착상태와 읽기/쓰기 성능을 보장하는 MVCC 모델]
  • [PostgreSQL - pgvector와 벡터 저장, 유사도 검색 패턴 개념]
  • [PostgreSQL - 벡터 인덱스 최적화와 벡터 검색과 전문 검색 결합 패턴]
  • [PostgreSQL - PostgreSQL 플러그인]
  • [PostgreSQL - PostGIS - 공간 쿼리와 GIST 인덱스, 지리 타입과 공간 쿼리를 위한 타입과 기본 함수]
  • [PostgreSQL - pg_search - 검색 엔진 없이 텍스트 검색 구현과 주의사항]
  • [PostgreSQL - 단일 인스턴스 한계를 극복하는 분산 패턴과 스케줄링, 분산 환경 구축 방법]
  • [PostgreSQL - Citus - 분산 테이블과 분산 쿼리를 위한 Extension과 데이터 분산 처리]
  • [PostgreSQL - pg_cron - PostgreSQL로 구성하는 CronJob]
  • [PostgreSQL - 스케줄러 + 분산 처리를 동시에 도입하는 주기적 집계 쿼리 패턴]

📖 Workflow-Driven Techniques for Large-Scale Traffic Processing

  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka + Debezium을 활용한 CDC 패턴 설계]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Temporal을 활용한 워크플로우 패턴]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Docker와 경량 이미지를 활용한 환경 구축 방법]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka에서의 메시지 Delivery Guarantee]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - 실시간 동기화의 핵심 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - MySQL Binary Log 기반의 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Binary Log 기반의 CDC 구현 플랫폼 Debezium이란?]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture Best Practice와 주의사항]

📖 Reactive Programming

📖 ElasticSearch

  • [ElasticSearch - Search Fundamentals & How Search Works]
  • [ElasticSearch - Korean-Optimized Search]
  • [ElasticSearch - Mapping & Data Types]
  • [ElasticSearch - Common Search Features]
  • [ElasticSearch - Building a Product Search Engine with Elasticsearch]
  • [ElasticSearch - Deploying Elasticsearch with Elastic Cloud]
  • [ElasticSearch - Managing Documents]
  • [ElasticSearch - Analysis & Mapping]
  • [ElasticSearch - Search Fundamentals]
  • [ElasticSearch - Query Joins]
  • [ElasticSearch - Processing Search Results]
  • [ElasticSearch - Aggregations]
  • [ElasticSearch - Tips for Improving Search Results]
  • [ElasticSearch - Elasticsearch Clients]
  • [ElasticSearch - Understanding How Elasticsearch Works]
  • [ElasticSearch - Monitoring Elasticsearch]
  • [ElasticSearch - Elasticsearch Troubleshooting]

Clone this wiki locally