> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/5-3.-ddd.md). # 5-3. DDD MSA 아키텍처 설계의 본론적 접근 방안, DDD에 대하여 ### DDD (Domain-Driven Design)의 사상적 기반과 핵심 가치 DDD는 마이크로서비스의 물리적 분리에 앞서 비즈니스 도메인의 본질을 깊이 있게 이해하고 모델링하기 위한 전략적·전술적 개발 방법론이자 핵심 아키텍처 설계 패러다임이다. **Bounded Context (바운디드 컨텍스트)를 통한 책임 분리** 동일한 이름을 가진 객체나 데이터 모델이라 하더라도 비즈니스의 진행 단계, 문맥(Context), 혹은 상황에 따라 그 의미와 본질적인 역할은 완전히 달라질 수밖에 없다. 예를 들어 쇼핑몰 시스템에서 Order(주문)라는 개념은 주문 캡처(Order Captured) 단계, 장바구니(Shopping Cart) 단계, 체크아웃 프로세스(Checkout Process), 결제 처리(Payment Processing), 재고 관리(Inventory System), 물류 창고 배송(Order Fulfillment/Warehouse System) 등 각 단계마다 다루는 속성과 책임이 완벽히 판이하다. Bounded Context는 도메인 모델의 유효 범위를 명확히 분리하여 책임 영역을 정밀하게 나누고, 의미적·가치적으로 고도로 응집된 독립적 도메인 경계를 지정하는 핵심 아키텍처 과정이다. 이를 통해 시스템의 복잡도를 획기적으로 낮추고 서비스 간의 간섭을 원천 차단한다. **Ubiquitous Language (유비쿼터스 언어) 기반의 의사소통** 시스템 구축 과정에서 발생하는 치명적인 버그와 정합성 붕괴는 대개 도메인 전문가와 개발자 간의 오해, 즉 불명확하고 파편화된 용어 사용에 따른 의사소통 비용에서 시작된다. 이를 해결하기 위해 특정 Bounded Context 내에서 완벽한 유효성을 지니며 도메인 전문가와 개발자, 아키텍트가 공통으로 바인딩하여 사용하는 단일화된 언어 체계가 바로 유비쿼터스 언어이다. 예를 들어 주문 완료 후의 상태를 'Shipped'와 같이 명확한 표준 언어로 정의하고 소통함으로써 불필요한 커뮤니케이션 오버헤드를 완벽하게 제거한다. 개발자는 이 유비쿼터스 언어에 철저히 기반하여 도메인 상태 관리 코드를 작성하고 Open API 규격을 명확하게 구성하게 된다. ### 에그리게이트(Aggregate) 기반의 데이터 무결성 및 트랜잭션 경계 설계 Bounded Context 내에서 정립된 도메인 객체와 요소들을 비즈니스 규칙에 맞게 묶어내고, 데이터의 강력한 일관성을 수호하는 구체적인 전술적 모델링 기법이다. **Aggregate (에그리게이트)의 정의와 역할** 에그리게이트는 관련 객체들을 하나의 의미 있는 단위로 묶어 데이터 일관성을 보장하는 로컬 트랜잭션의 최소 요소이자 유일한 경계 단위이다. 비즈니스 제약 조건을 만족하기 위해 항상 함께 변경되어야 하는 객체들의 응집된 집합체체로 볼 수 있다. **Aggregate Root (에그리게이트 루트) 중심의 인터페이스 및 데이터 통제 규칙** 수많은 에그리게이트 컴포넌트 중 외부에서 직접 접근할 수 있는 유일한 통로이자 대표 인터페이스가 바로 에그리게이트 루트(Aggregate Root)이다. 도메인의 비즈니스 규칙과 트랜잭션 일관성을 완벽하게 유지하기 위해 아래와 같은 철저한 진입 경로 통제 메커니즘을 강제한다. * **유일한 진입 경로 보장**: 에그리게이트 내부에 포함된 하위 엔티티(Entity)나 밸류 오브젝트(Value Object)들은 외부에 결코 노출되지 않으며, 외부 시스템이나 타 마이크로서비스 레이어에서는 오직 에그리게이트 루트만을 통해서만 내부 데이터에 접근할 수 있다. 이는 데이터 무결성을 보장할 수 있는 시스템 상의 유일한 경로가 된다. * **내부 엔티티 직접 접근 금지**: 예를 들어 주문 에그리게이트 내부에 Order(Aggregate Root), OrderItem(Entity), ShippingAddress(Value Object), PaymentInfo(Value Object) 등이 구조적으로 묶여 있다면, 외부에서는 `order.addItem(...)`과 같이 루트 객체의 메서드를 통해서만 연산 및 상태 변경을 요청해야 한다. 루트를 거치지 않고 하부 엔티티인 `orderItem.changeQuantity()`를 외부에서 직접 호출하여 데이터 상태를 변형하는 행위는 도메인 설계 규칙상 엄격히 금지된다. * **도메인 규칙 통제와 일관성 유지**: 에그리게이트 루트는 단순히 데이터를 실어 나르는 단순한 Java 객체(Entity/DTO)들의 기계적인 합이 아니며, 유입되는 요청에 대해 도메인 제약 조건을 검증하고 비즈니스 규칙을 강제함으로써 도메인 전체의 무결성을 철저히 지키고 제어하는 강력한 경계 메커니즘으로 동작한다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/5-3.-ddd.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.