도메인 주도 설계

실무에서 써먹는 불변성

소프트웨어에서 말하는 불변성Immutability이라는 것이 있다. 즉 변하지 않는다는 것이다. 다른 말로는 읽기 전용이라고도 해석할 수 있다. 무엇이 변하지 않는다는 것일까? 객체 지향 프로그래밍으로 좁혀서 생각해 보면 한번 만들어진 객체가 변하지 않다는 것을 의미한다. 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.(중략)불변 클래스는 가변 클래스보다

커머스 코드 자산화 개발 일지-2 상품을 팔지 않고 오퍼를 판다

지난 이야기 지난 글에서는 개발 일지를 쓰게 된 배경을 설명했고 간단하게 상품 마이크로서비스를 구현해 보았다. 상품을 보다 유연하게 다루기 몇 년 전 함께 일했던 기획자가 상품(Product)을 분리하자는 제안을 했다. 상품에는 잘 변하지 않는 요소(바코드, 제조사, 원가 등)와 자주 변하는 요소(판매 조건 등)가 있는데 상품

MSA에서 메시징 트랜잭션 처리하기

비동기 메시지를 사용하여 상호 간에 통신하는 방식을 메시징Messaging[1]이라고 부른다. 마이크로서비스 환경에서 비동기 처리 시 보통 카프카Kafka나 래빗엠큐RabbitMQ 같은 메시지 브로커Message Broker를 사용하여 메시징을 구현한다. 아래와 같이 마이크로서비스들이 메시징을 통해 협업하여 주문을 처리한다고 가정해보자. OrderService는 주문 상태 이벤트(예. ORDER_CREATED, ORDER_CANCELLED 등)를 메시지 브로커에 발행하고 이벤트에

DDD 값 객체와 마이크로서비스

이 글은 도메인 주도 설계Domain-Driven Design(이하 DDD)에서 말하는 값 객체Value Object가 무엇인지 알아보고 마이크로서비스 환경에서 값 객체를 활용하는 법을 다룬다. 값 객체란 무엇인가? 전자 상거래 사이트에서 상품을 받을 주소(배송지)를 입력하고 주문한다고 생각해 보자. 시스템에서 배송지를 임의로 수정한다면 상품은 정상적으로 배송되지 못할 것이다. 따라서 시스템은 배송지를

ID로 다른 애그리게잇을 참조하라

필자는 지난 글 전반부에서 도메인 주도 설계Domain-Driven Design에서 말하는 구조물 중 하나인 조립물AGGREGATE[1]에 대해 이야기했다. 조립물을 구현하다 보면 다른 조립물을 참조해야 할 때가 있다. 이를 구현하는 방식은 크게 조립물의 루트 엔터티Root Entity 객체를 참조(포인터) 하는 것과 식별자로 어디서든 쓸 수 있는 값을 사용하는 방법(ID)이

애그리게잇 하나에 리파지토리 하나

필자는 도메인 주도 설계Domain-Driven Design(이하 DDD) 빌딩 블록Building blocks[1]으로 애플리케이션을 구현하면서 엔티티ENTITY[2] 마다 리파지토리REPOSITORY를 만드는 것을 자주 보았는데 자세히 살펴보면 여러 엔티티를 묶어서 하나처럼 사용하는 경우가 대부분이었다. DDD에서는 이러한 연관 객체의 묶음을 애그리게잇AGGREGATE이라고 정의하고 애그리게잇에 포함된 특정 엔티티를 루트Root 엔티티라고 부른다. 그리고 리파지토리를 만들 때