DDD 프레임워크 - Axon

주요링크 

• https://www.axon.com/
• https://www.axoniq.io/blog/axon-and-akka-how-do-they-compare

차이점 - Axib VS Akka

1. CQRS/ES 패턴과 플랫폼의 필요성 [6]

• CQRS(Command Query RESponsibility Separation)와 ES(Event Sourcing) 패턴은 시스템을 단순한 상태(State) 중심이 아닌 이벤트와 상태의 조합으로 바라보는 방식을 강조함 [6]

• DDD(Domain Driven DESign)와 결합하면, 반응성(Reactive), 확장성(Scalable), 분산성(Distributed), 이벤트 기반(Event-Driven) 애플리케이션을 구축하는 데 핵심이 됨 [7]

• 이러한 패턴의 구현은 복잡하며, 자체적으로 프레임워크를 개발하면 실패 확률이 높아짐 [8]

• 목적에 맞게 설계된 플랫폼을 사용하는 것이 현명하며, 개발자가 비즈니스 코드에 집중할 수 있도록 다양한 도구와 생태계를 제공함 [10]

• 본 글에서는 Akka(Lightbend)와 Axon(AxonIQ) 두 플랫폼을 비교함 [11]

2. CQRS/ES 플랫폼의 핵심 구성요소 [14]

• CQRS/ES 플랫폼은 두 가지 주요 측면을 가짐 [16]

  • 논리적 인프라: DDD 개념을 활용한 CQRS/ES API 제공 [17]

  • 물리적 인프라: 이벤트 저장/조회 및 메시지 라우팅(명령/질의/이벤트) 지원 [18]

• 이 두 측면이 모두 구현되어야 목적에 맞는 CQRS/ES 플랫폼으로 볼 수 있음 [14]

3. 논리적 인프라: Akka의 특징 [20]

• Akka는 Actor 모델 기반으로, 장애 허용, 동시성, 분산 시스템 구축에 적합함 [21]

  • 메시지는 각 Actor의 "메일박스"로 전달되어 비동기적으로 처리됨 [21]

• Akka Persistence 모듈의 "Akka Persistence Typed API"(Scala/Java)로 ES/CQRS 구현 가능 [22]

  • "Aggregate" 개념을 활용하지만, DDD에서의 Aggregate를 명확히 표시하는 기능은 없음 [23]

  • 어떤 엔티티든 이벤트 소싱 Actor로 만들 수 있음 [24]

• Event Sourced Actor의 구성 요소:

  • 상태(State), 명령(Command), 명령 핸들러(Command Handler), 이벤트(Event), 이벤트 핸들러(Event Handler), 응답(Reply) [25]

  • 모든 것은 "EventSourcedBehavior"로 묶임 [26]

• 명령 메시지 처리 흐름:

  • Actor가 명령 메시지 수신 [28]

  • Command Handler가 과거 이벤트를 재생해 상태 로드 [29]

  • 명령 검증 후, 실행 결과에 따라 Effect 반환(이벤트 저장, 무동작, Actor 중지, 예외 발생 등) [30]

  • 이벤트 저장 성공 시, 이벤트 핸들러가 상태 변경 [32]

  • 이벤트 핸들러는 순수 함수로 작성해야 하며, Aggregate 인스턴스화 및 이벤트 재생 시 사용됨 [33]

• Akka 문서에서 Event Sourced Actor 작성 가이드 제공 [35]

• Query 모델 구축을 위해 "Akka Projections" 제공

  • Akka Stream Source를 활용해 읽기/질의 모델 생성 가능

  • 오프셋 추적, 재생, 복원력 향상 지원 [36]

• 스냅샷, 스키마 진화, 테스트, 상태 머신 등도 지원 [37]

4. 논리적 인프라: Axon의 특징 [38]

• Axon Framework는 DDD 기반 CQRS/ES 애플리케이션 구축을 위한 완전한 API 제공 [39]

• 모든 명령/질의/이벤트를 "메시지"로 취급 [40]

  • 위치 투명성(Location Transparency): 컴포넌트 간 명확한 메시지 전달 방식으로 상호작용 [41]

  • 메시지 발신자가 수신자를 알 필요가 없어, 컴포넌트 분해 및 진화가 용이함 [42]

• Spring Boot와의 통합 지원, 직접 구성도 가능 [43]

• 명령 메시지 처리 흐름:

  • "Command Bus"에 명령 메시지 등록, 적절한 Command Handler로 라우팅 [45]

  • 컴포넌트 간 의존성 없이 확장/분산 가능 [47]

• 이벤트 소싱 Aggregate 구축을 위한 DDD/CQRS 기반 어노테이션 제공 [48]

  • Aggregate, Command Handler, Event Sourcing Handler, Event Handler 표시 가능 [49]

  • Command Handler가 이벤트를 발생시키고, Aggregate가 상태 변경 후 이벤트 저장소에 저장 [50]

  • Aggregate 내 Event Handler는 상태 변경만 담당 [51]

• 프로젝션/읽기 모델 구축을 위한 "Event Processor" 제공

  • 오프셋 추적, 예외 처리, 세분화 등 지원 [52]

• "Event Bus", "Query Bus"도 제공하여 이벤트 및 질의 메시지 라우팅 담당 [54]

• 스냅샷, 스키마 진화(Upcaster), 테스트, 사가(Saga) 등 지원 [56]

5. 물리적 인프라: Akka의 특징 [57]

• 이벤트/스냅샷 저장소로 Cassandra, JDBC, Slick DB 등 다양한 데이터 소스 사용 가능 [57]

  • 프로젝션은 Kafka 등 다양한 Akka Stream Source 활용 가능 [57]

• 클러스터링 및 "Replicated Event Sourcing"(작성 시점 기준 WIP) 등 분산 기능 제공 [57]

6. 물리적 인프라: Axon의 특징 [58]

• Axon Server: 이벤트 소싱에 최적화된 전용 이벤트 저장소 및 메시지 라우터 역할 [60]

  • Command Bus, Query Bus, Event Bus의 물리적 구현체로 동작 [61]

• Axon Server SE(단일 노드)와 Axon Server EE(엔터프라이즈, 클러스터링 지원) 두 가지 에디션 제공 [62]

• Axon Server 외에도 오픈소스 컴포넌트 활용 가능

  • 예: Spring Cloud로 분산 Command Bus, PostgrES 등 관계형 DB를 이벤트 저장소로 사용 [64]

7. 결론 및 통합 가능성 [66]

• Axon과 Akka 모두 엔터프라이즈급 CQRS/ES 플랫폼으로, 애플리케이션 구축에 적합함 [67]

• 두 플랫폼의 통합 예시로, Akka의 이벤트 저널로 Axon Server를 사용하는 방안도 제안됨 [67]

8. 참고 및 저자 정보 [68]

• 저자: Vijay Nair, DDD, CQRS, 이벤트 소싱 전문가, "Practical Domain-Driven DESign with Enterprise Java" 저자 [68]

🧭 Axon Framework란?

Axon Framework는 복잡한 도메인을 가진 시스템에서 **도메인 주도 설계(DDD)**와 함께 CQRS(Command Query Responsibility Segregation) 및 Event Sourcing을 실용적으로 구현하도록 설계된 프레임워크입니다.

• 주로 Spring Boot 기반으로 많이 사용됩니다.

• AxonIQ라는 회사에서 관리하며, 클라우드 및 On-Premise용 플랫폼인 Axon Server도 제공합니다.

🎯 Axon의 핵심 아키텍처

1. Command (명령)

• 시스템에서 "무언가를 해달라"는 요청

• 예: CreateOrderCommand, ChangeEmailCommand

• 처리자는 @CommandHandler로 구현

@CommandHandler
fun handle(cmd: CreateOrderCommand) {
    AggregateLifecycle.apply(OrderCreatedEvent(...))
}

2. Event (이벤트)

• 이미 발생한 사실

• 예: OrderCreatedEvent, EmailChangedEvent

• Aggregate는 이벤트 기반으로 상태를 변화

@EventSourcingHandler
fun on(event: OrderCreatedEvent) {
    this.orderId = event.orderId
}

3. Query (조회)

• Command와 분리된 읽기 모델

• @QueryHandler로 처리

• 읽기 성능과 확장성을 높이기 위한 CQRS 패턴 적용

@QueryHandler
fun handle(query: FindOrderQuery): OrderView {
    return repository.findById(query.orderId)
}

4. Aggregate

• DDD에서 말하는 트랜잭션 단위의 루트 객체

• @Aggregate 어노테이션으로 정의

• 
  

@Aggregate
class OrderAggregate {
    @AggregateIdentifier
    lateinit var orderId: String
}

5. Event Store

• 이벤트를 DB 또는 Axon Server에 저장

• 이벤트 소싱 방식이면, 상태 대신 이벤트 이력으로 복원

6. Saga

• 장기간 걸리는 프로세스(예: 결제 완료 후 배송)를 관리

• 여러 Aggregate 간의 흐름을 이벤트 기반으로 조정

@Saga
class OrderProcessingSaga {
    @SagaEventHandler(...)
    fun on(OrderCreatedEvent e) {
        // 다음 행동 트리거
    }
}

💎 Axon Framework의 장점

📦 Axon Server (선택사항)

• Axon 전용 이벤트 저장소 및 라우팅 서버

• Kafka, RabbitMQ 없이도 분산 처리 가능

• 클러스터링, 메시지 라우팅, 모니터링 포함

🎯 Axon은 언제 적합할까?

🧱 Axon 구성요소 요약 도표

🧭 Akka vs Axon DDD 프레임워크 비교

아래는 DDD 패턴을 구현할 때의 Axon vs Akka(Pekko) 기본 예제 비교입니다. 공통 시나리오는 간단한 주문(Order) 생성 및 상태 변경이며, 모두 Kotlin 기준입니다.

✅ 시나리오

• 명령(Command): CreateOrderCommand(orderId, product)

• 이벤트(Event): OrderCreatedEvent(orderId, product)

• Aggregate는 OrderAggregate로 구현

🟦 1. Axon Framework - Kotlin 예제

@Aggregate
class OrderAggregate() {

    @AggregateIdentifier
    lateinit var orderId: String

    constructor(cmd: CreateOrderCommand) : this() {
        AggregateLifecycle.apply(OrderCreatedEvent(cmd.orderId, cmd.product))
    }

    @EventSourcingHandler
    fun on(event: OrderCreatedEvent) {
        this.orderId = event.orderId
        println("Order created: ${event.product}")
    }
}

data class CreateOrderCommand(val orderId: String, val product: String)
data class OrderCreatedEvent(val orderId: String, val product: String)

🟢 Axon 특징

• @Aggregate, @CommandHandler, @EventSourcingHandler 어노테이션만 붙이면 핵심 구조 완료

• 이벤트 저장, 복원, CQRS QueryModel 자동 처리 가능

🟧 2. Akka (Pekko) Persistence - Kotlin 예제

sealed interface Command
data class CreateOrder(val orderId: String, val product: String) : Command

sealed interface Event
data class OrderCreated(val orderId: String, val product: String) : Event

data class OrderState(val orderId: String? = null, val product: String? = null) {
    fun apply(event: OrderCreated) = this.copy(orderId = event.orderId, product = event.product)
}

class OrderAggregate private constructor(
    private val context: akka.actor.typed.javadsl.ActorContext<Command>
) : EventSourcedBehavior<Command, Event, OrderState>(
    PersistenceId.ofUniqueId("order-${context.self.path().name}"),
    OrderState()
) {
    companion object {
        fun create(): Behavior<Command> = Behaviors.setup { ctx -> OrderAggregate(ctx) }
    }

    override fun commandHandler(): CommandHandler<Command, Event, OrderState> =
        newCommandHandlerBuilder()
            .forAnyState()
            .onCommand(CreateOrder::class.java) { state, cmd ->
                Effect().persist(OrderCreated(cmd.orderId, cmd.product))
            }.build()

    override fun eventHandler(): EventHandler<OrderState, Event> =
        newEventHandlerBuilder()
            .forAnyState()
            .onEvent(OrderCreated::class.java) { state, event ->
                state.apply(event)
            }.build()
}

🟡 Akka 특징

• 명시적인 FSM 스타일 구조

• 이벤트 핸들링과 상태 관리 수동 구현

• Behavior, CommandHandler, EventHandler 분리

• 복잡하지만 분산 시스템/Actor 모델에 적합

📊 비교 요약

🔚 결론

• Axon: DDD + CQRS + Event Sourcing을 간단하게 구조화하고 싶은 경우 → 선언형으로 빠르게 구현 가능

• Akka: 고성능, 실시간성, 분산 처리 중심 시스템에서 더 유연하게 동작 → 자유도는 높지만 복잡도도 높음

서로다른진영 가령 자바와 닷넷이 상호 경쟁하면서도 서로영향을 주며발전했듯이 - 플스vs엑박처럼

한가지 진영만 우월하다고 타진영을 무시하는것보다. 다른 진영도 참고하면서 학습하는 방식은 자신이 숙련도가 높다라고 믿는 진영에서도 더 발전하는 오픈마인드식 접근이라 생각이들어 AKKA에 대응하는 또다른 컨셉을 프레임워크를 조사해보았습니다.