nyambu 님의 블로그

1. 전통적인 CRUD 아키텍처의 한계1-1. 명령과 조회가 뒤엉킨 서비스 구조 전통적인 애플리케이션은 대부분 하나의 도메인 모델로 명령(Command)과 조회(Query)을 동시에 처리한다. 예를 들어 OrderService는 주문 생성과 동시에 주문 내역 조회도 담당하며, 이는 단일 모델로 모든 역할을 떠안는 구조다. 개발 초기에는 간단해 보일 수 있으나, 시간이 지나면 기능이 복잡해지고 데이터 처리 요구가 다양해지면서 코드의 응집도가 낮아지고 유지보수가 어려워진다. 게다가 명령과 조회는 설계 목표 자체가 다르다. 명령은 데이터 정합성과 비즈니스 규칙을 중심으로 설계되어야 하고, 조회는 성능과 응답 속도에 초점을 맞춰야 한다. 두 책임을 한 클래스가 동시에 지는 것은 단일 책임 원칙(SRP)을 위배..

1. 애그리거트의 핵심 역할1-1. 비즈니스 무결성을 보장하는 경계 애그리거트(Aggregate)는 도메인 주도 설계(DDD)에서 비즈니스 규칙의 일관성을 유지하는 최소 단위로 사용된다. 즉, 하나의 트랜잭션 안에서 상태 변경이 일어날 수 있는 객체의 범위를 정의한다. 여러 엔터티와 값 객체가 구성돼 있을 수 있지만, 외부에서는 루트 엔터티를 통해서만 조작 가능하다. 예를 들어 Order는 루트이고, 그 안에 OrderLine, ShippingInfo, PaymentInfo 등의 하위 객체가 있다. 외부에서는 직접 OrderLine을 수정할 수 없고, 반드시 Order를 통해 추가/삭제해야 한다. 이러한 구조는 객체 간 무결성을 유지하며, 변경 범위를 명확히 제한해준다. 결국 애그리거트는 단순한 객체 ..

1. 객체지향에서의 본질적인 구분1-1. 왜 두 개념이 필요한가? 소프트웨어 설계에서 모든 객체를 동일하게 취급하면, 코드가 복잡해지고 유지보수성이 떨어진다. 그래서 객체의 ‘역할’에 따라 개념적으로 구분하는 것이 중요하다. Value Object와 Entity의 구분은 바로 이 설계 명확성을 높이기 위한 핵심적인 전략이다. Value Object는 그 값 자체가 중요한 객체이고, Entity는 고유한 정체성을 가진 객체다. 동일한 데이터를 가진 두 객체라도, Value Object라면 하나로 취급되지만, Entity라면 각각 별개의 존재다. 이 구분이 없다면 동일성, 식별, 변경 추적 등의 이슈가 설계 전반에 영향을 미치게 된다. 이러한 구분은 단지 철학적 개념이 아니라, 모델링의 의도와 코딩 구현 ..

1. 도메인 주도 설계란 무엇인가?1-1. 복잡한 소프트웨어를 다루는 새로운 접근법 도메인 주도 설계(Domain-Driven Design, DDD)는 단순한 설계 기법이 아니라, 복잡한 비즈니스 요구사항을 명확히 모델링하고 지속적으로 진화시켜가는 방법론이다. 전통적인 시스템 설계는 기능 중심이었지만, DDD는 "비즈니스 개념을 코드에 반영한다"는 철학을 중심으로 한다. DDD는 에릭 에반스(Eric Evans)의 저서 『Domain-Driven Design』에서 처음 정립되었으며, 복잡한 도메인 로직을 개발자와 도메인 전문가가 공통 언어(Ubiquitous Language) 로 공유하며 점진적으로 모델링하는 방식이다. 즉, 비즈니스 언어를 모델로 승화시키는 과정이다. 이 철학은 단순히 객체지향을 더..