도메인 주도 설계(DDD) 마스터 지침

도메인 주도 설계(DDD) 마스터 지침

2025-09-28, G25DR

1. DDD의 근본 철학을 이해하고 수용하라

1.1 도메인 주도 설계의 본질과 가치를 명확히 인식하라

도메인 주도 설계(DDD)는 에릭 에반스가 2003년 동명의 저서를 통해 도입한 소프트웨어 설계 원칙들의 집합이다.1 너희는 이 원칙들을 복잡한 소프트웨어 개발의 핵심 접근법으로 인식해야 한다. DDD의 근본 목적은 단순한 기능 구현을 넘어, 핵심 도메인에 집중하고 도메인 전문가와 소프트웨어 전문가의 창의적인 협력을 통해 비즈니스 모델을 탐구하고 코드로 구현하는 데 있다.1

근본 원칙을 수용하라: 복잡한 소프트웨어 프로젝트의 성공을 위해, 핵심 도메인에 집중하고, 도메인 전문가(Domain Practitioners)와 소프트웨어 전문가(Software Practitioners) 간의 협력적 탐구를 통해 모델을 진화시키며, 명시적인 경계(Bounded Context) 내에서 유비쿼터스 언어(Ubiquitous Language)를 사용하라.1

설계 중심을 전환하라: 너희가 구축하는 시스템의 설계가 프레임워크, 아키텍처, 또는 특정 프로그래밍 언어와 같은 기술적 요인에 의해 주도되는 것을 절대 허용하지 마라. 설계는 오직 **도메인(Domain)**의 복잡한 요구사항과 논리에 의해 주도되도록 강제해야 한다.1 이 접근법은 기술 종속성을 제거하고, 개발팀이 비즈니스 문제를 해결하는 데 집중하도록 만든다.

복잡한 도메인에만 집중하라: DDD의 패턴들은 구현 과정에서 일정 수준의 오버헤드를 유발할 수 있다.2 따라서 DDD는 비즈니스 규칙이 도전적이고 복잡하여, 이를 이해하고 구현하는 과정이 어려운 소프트웨어에 가장 큰 이점을 제공한다.1 단순한 CRUD 작업이 주를 이루는 시스템에는 전통적인 아키텍처를 적용하는 것이 더 효율적일 수 있음을 인지하고, 적용 대상을 전략적으로 선정하라.

1.2 개발팀 중심의 사고방식을 도메인 중심의 사고방식으로 전환하라

지식 습득을 최우선하라: 개발자들은 코드를 작성하기 전에 도메인 지식을 심화하여 구축해야 함을 명심하라. 에릭 에반스는 소프트웨어 자체가 도메인을 반영하도록 만들 것을 권고했다.3 이는 단순한 지식 전달을 넘어, 개발자가 능동적으로 비즈니스 전문가와 함께 모델을 다듬는 지식 압착(Knowledge Crunching) 과정을 통해 이루어져야 한다.4

불변식을 정립하라: 도메인 전문가, 특히 현업 종사자(예: 영업 조직)는 현실 세계에서 파편화되고 비일관적인 행동 양식이나 규칙을 가질 수 있다.5 너희는 이러한 혼돈스러운 정보의 흐름을 그대로 코드에 반영해서는 안 된다. 수많은 행동들을 면밀히 모아 분석하고, 시스템 내에서 논리적으로 반드시 지켜져야 할 **불변식(Invariants)**을 개발자의 책임하에 도출하라.5 이 불변식이 도메인 모델의 핵심 논리가 되며, 비즈니스가 너희가 만든 모델에 따르도록 강제해야 한다.5 이는 개발자의 역할을 기술 구현에서 비즈니스 원칙 정립으로 격상시키는 행위이다.

모델 주도 설계를 실천하라: DDD는 모델 주도 설계(Model-Driven Design, MDD)를 통해 모델과 구현을 긴밀하게 연결할 것을 요구한다.4 코드를 읽는 행위가 도메인 모델을 이해하는 과정이 되도록 설계해야 한다.3 도메인 모델에 데이터베이스 쿼리 방식이나 외부 시스템과의 통신 방법 등 기술적 상세를 혼입한다면 6, DDD의 근본 철학이 무너짐을 명심하라. 따라서 기술적 관심사로부터 도메인 모델을 분리하는 것은 철학적 원칙을 지키기 위한 아키텍처적 명령임을 인식하라.

너희의 프로젝트를 구조화하고 관리하기 위해, DDD의 접근 방식은 크게 전략적 설계와 전술적 설계로 나뉜다.7 다음 표를 통해 이 둘의 역할 구분을 명확히 숙지하라.

Table 1: 전략적 설계와 전술적 설계의 역할 구분

구분목표주요 활동 및 패턴적용 범위
전략적 설계대규모 도메인 분할 및 구조화바운디드 컨텍스트, 컨텍스트 맵, 유비쿼터스 언어, ACL시스템 전체 (경계 정의 및 상호작용 관리)
전술적 설계바운디드 컨텍스트 내부의 모델 구현엔티티, 값 객체, 애그리게이트, 리포지토리, 서비스단일 바운디드 컨텍스트 내부

2. 전략적 설계: 비즈니스 도메인을 분할하고 정의하라

전략적 설계는 복잡한 도메인을 다루는 고수준의 접근법이다. 하나의 도메인을 해결하고자 하는 문제에 따라 여러 하위 도메인으로 나누는 방법을 말한다.9

2.1 유비쿼터스 언어(Ubiquitous Language)를 정립하고 팀 내에서 엄격히 준수하라

팀 전체의 공통 언어를 정의하라: 유비쿼터스 언어는 도메인 전문가와 소프트웨어 전문가 간에 단일하고 명확한 용어를 사용하여 의사소통의 오류를 제거하고 도메인 개념을 통일하는 데 필수적이다.1 팀 내에서 ’주문’과 ’판매’와 같은 핵심 용어가 서로 다른 의미로 사용되는 헛소리가 돌아다니는 것을 즉각적으로 막아라.5

코드에 언어를 반영하라: 이 언어를 소스 코드의 모든 요소에 정확하게 반영하여 코드의 가독성을 높이고 도메인 모델을 지원하라.1 클래스 이름, 메서드 이름, 변수 이름, 패키지 구조 등 모든 명명 체계가 유비쿼터스 언어와 일치해야 한다.1

서비스 작명 기준을 통일하라: 도메인 서비스의 작업명은 반드시 유비쿼터스 언어에서 파생되어야 하며, 해당 작업의 매개변수와 결과는 기술적 원시 타입이 아닌 도메인 객체로 정의하여 도메인 모델을 유지해야 한다.4

2.2 바운디드 컨텍스트(Bounded Context)를 정의하고 그 경계를 확립하라

논리적 경계를 설정하라: 바운디드 컨텍스트(BC)는 DDD 전략적 설계의 핵심 패턴이며 10, 도메인을 논리적으로 분리하여 각 부분이 독립적인 경계를 가지도록 나누어 복잡성을 관리하는 데 필수적이다.11 BC는 도메인 모델이 적용되는 명시적인 경계 영역을 의미한다.

언어 변화를 추적하라: 유비쿼터스 언어가 의미를 달리하는 지점에서 BC의 경계가 생긴다.12 예를 들어, ’고객’이라는 용어가 영업팀(잠재 고객)과 회계팀(결제 완료 고객)에서 다르게 해석된다면, 이들은 별도의 BC로 분리되어야 한다. 각 BC는 구현하는 하위 도메인에 맞는 자체 모델을 가져야 하며 13, 하위 도메인 모델들이 섞이지 않도록 물리적인 패키지 구분을 두어 격리해야 한다.13

2.3 컨텍스트 맵(Context Map)을 작성하여 도메인 간의 관계를 시각화하라

아키텍처 결정을 지원하라: 바운디드 컨텍스트를 정의한 후, 컨텍스트 맵을 작성하여 분리된 컨텍스트 간의 관계를 명확히 시각화하라.10 이 맵은 시스템의 높은 수준의 관점을 제공하며, 아키텍처 결정이나 통합 전략 수립에 활용되어야 한다.14 BC의 경계는 비즈니스의 관점 변화를 의미하며, 컨텍스트 맵은 조직의 역학 관계를 이해하고 조직적 커뮤니케이션의 분할 지점을 파악하는 데도 도움을 준다.12

2.4 바운디드 컨텍스트 간의 관계 패턴을 명시하고 통합 전략을 구축하라

바운디드 컨텍스트 간의 통합은 시스템 복잡성을 유발하는 주요 요소이므로, 각 관계에 대해 명확한 전략 패턴을 적용해야 한다.

방어 전략을 구축하라 (ACL): 외부 컨텍스트, 특히 레거시 시스템 12이나 내부 모델링이 적용되지 않은 큰 진흙공(Big Ball Of Mud) 14처럼 품질이 낮거나 신뢰할 수 없는 업스트림 시스템에 의존하는 경우, 반드시 **부패 방지 계층(Anticorruption Layer, ACL)**을 도입하여 내부 모델을 방어해야 한다.14 ACL은 다운스트림 컨텍스트의 깨끗한 모델을 업스트림 모델의 복잡성과 오염으로부터 보호하는 변환 계층 역할을 수행한다. 이 방어적 설계는 아키텍트의 생존 전략으로 간주하라.

표준화된 통신을 정의하라 (OHS & PL): 외부 서비스에 접근 가능한 프로토콜이 명확히 정의된 **오픈 호스트 서비스(Open Host Service, OHS)**를 정의하라.14 OHS를 통해 상호작용할 때는, 변환 계층의 기준이 되는 **발행된 언어(Published Language, PL)**를 문서화하고 공유 언어로 활용하여 안정적인 통합을 보장해야 한다.14

불필요한 관계를 제거하라: 두 바운디드 컨텍스트 사이에 유의미한 관계나 상호작용이 없다면, **분리된 방법(Separate Ways)**을 명확히 선언하고 독립적으로 발전시키라.14 이는 불필요한 통합 비용을 절감하고 각 팀이 작은 범위 내에서 전문적인 해결책을 찾을 수 있도록 한다.

Table 2: 바운디드 컨텍스트 간 상호작용 패턴 및 지침

패턴목표관계 유형지침
부패 방지 계층 (ACL)다운스트림 모델 방어방어적 통합외부 모델 오염 방지를 위해 변환 및 격리 계층을 반드시 도입하라.14
오픈 호스트 서비스 (OHS)공개된 접근 표준 정의공개된 상호작용외부가 접근할 수 있는 명확하고 확장 가능한 프로토콜을 정의하라.14
발행된 언어 (PL)표준화된 통신 언어상호작용 기준BC 간 변환을 처리하기 위한 잘 문서화된 공유 언어를 사용하라.14
분리된 방법 (Separate Ways)독립적인 발전무관계 선언불필요한 통합을 피하고 각 BC가 자체적으로 해결책을 찾도록 허용하라.14

3. 전술적 설계: 핵심 빌딩 블록을 구현하라

전술적 설계는 정의된 바운디드 컨텍스트 내부에서 모델을 구현하는 구체적인 패턴을 의미한다.

3.1 엔티티(Entity)와 값 객체(Value Object)의 역할을 명확히 구분하라

도메인 모델링을 위한 핵심 구성 요소인 엔티티와 값 객체의 구분을 명확히 하고, 다음 표의 지침을 따르라.15

Table 3: DDD 핵심 빌딩 블록 비교 및 구현 지침

빌딩 블록식별성 (Identity)가변성 (Mutability)동일성 판단 기준
엔티티 (Entity)고유한 식별자 소유 15가변적 17식별자를 통해 판단
값 객체 (Value Object)식별자 없음 17불변적 (Immutable) 17속성 값들을 통해 판단 16

엔티티는 식별성을 가져야 한다: 엔티티는 고유 식별자(Unique ID)를 가지며, 시간이 지나거나 속성이 변경되더라도 그 연속성이 유지되어야 한다.15 식별자는 시스템 내에서 엔티티를 조회하거나 검색하는 데 사용된다.15

값 객체는 불변성을 강제하라: 값 객체는 식별자가 없고 오직 그 속성 값만으로 정의되며, 예를 들어 주소나 금액(Monetary Sum)이 이에 해당한다.16 값 객체를 정의할 때 반드시 불변(Immutable)하도록 구현해야 한다.17 불변성은 값 객체를 공유하는 여러 엔티티들 간에 의도치 않은 상태 변경(데이터 오염)이 발생하는 것을 방지하는 핵심 메커니즘이다. 또한, 값 객체는 생성 단계에서부터 데이터의 유효성 검증을 완료하여 비즈니스 불변식을 충족시키고, 항상 유효한 상태로만 존재하도록 강제해야 한다.17

3.2 애그리게이트(Aggregate)를 일관성 경계의 핵심으로 설정하고 루트를 통제하라

트랜잭션 단위를 정의하라: 복잡한 도메인에서 엔티티와 값 객체만으로는 일관성을 유지하기 어렵다. 따라서 연관된 엔티티와 값 객체를 하나의 논리적 단위로 묶어 **애그리게이트(Aggregate)**를 정의하고, 이를 데이터 변경을 위한 **단일 단위(Unit)**로 취급하라.3 애그리게이트는 곧 트랜잭션 경계이다.17

강력한 불변식을 유지하라: 애그리게이트는 그 내부의 **참된 비즈니스 불변식(True Business Invariants)**을 원자적으로(Atomically) 유지해야 한다.2 애그리게이트 내의 모든 변경은 단일 트랜잭션 내에서 처리되어야 하며, 이는 변경이 모두 성공하거나 모두 실패하는 강력한 일관성(Atomic Consistency)을 보장해야 함을 의미한다.17 유효성 검증을 미룰 수 없는 모든 비즈니스 규칙은 이 경계 내에서 처리되어야 한다.

루트를 통해 접근을 통제하라: 애그리게이트 내에서 오직 하나의 엔티티를 **애그리게이트 루트(Aggregate Root)**로 선택하고, 외부 객체가 애그리게이트 내부의 다른 객체들에 접근할 때는 반드시 이 루트를 통해서만 접근하도록 엄격히 통제하라.4 루트만이 내부 객체에 대한 참조를 가질 수 있으며, 이 통제 메커니즘은 내부 객체의 상태 변화가 애그리게이트 전체의 무결성을 훼손하는 것을 원천적으로 막는다.4

3.3 리포지토리 및 팩토리 패턴을 사용하여 인프라를 분리하라

리포지토리를 인터페이스로 선언하라: 리포지토리(Repository) 패턴은 도메인 객체를 영속화하는 작업을 추상화하여 도메인 모델과 데이터베이스 접근 로직을 분리하는 것을 목표로 한다.20 도메인 계층에는 리포지토리를 순수 인터페이스로 선언하고, 실제 데이터 접근 로직은 인프라 계층의 구현체(Adapter)에 분리하여 의존성 역전 원칙(DIP)을 준수하라.20

팩토리로 복잡한 생성을 캡슐화하라: 애그리게이트나 복잡한 값 객체의 생성 과정이 복잡해지거나 내부 구조를 클라이언트에게 노출할 때, **팩토리(Factory)**를 사용하여 생성 로직을 캡슐화해야 한다.3 팩토리는 클라이언트가 객체의 내부 세부 사항을 알 필요 없이, 일관성 있고 유효성이 보장된 객체 또는 애그리게이트 전체를 생성할 수 있도록 표준화된 인스턴스화를 보장한다.3

3.4 도메인 서비스와 애플리케이션 서비스의 역할을 구분하고 적절히 활용하라

도메인 서비스의 기준을 지켜라: 도메인 서비스는 엔티티나 애그리게이트에 속하기 어려운 비즈니스 로직, 예를 들어 여러 엔티티 간의 협력이 필요한 작업이나 특정 계산(환율 계산 등)을 처리하는 객체이다.19 도메인 서비스는 반드시 도메인 개념과 관련된 작업을 수행해야 하며, 상태 비저장(Stateless) 원칙을 엄격히 준수하라.4 도메인 서비스를 남용하여 엔티티나 값 객체의 행위(Behavior)를 박탈하는 오류를 저지르지 않도록 경계하라.4

애플리케이션 서비스는 조정자 역할을 수행하라: 애플리케이션 서비스는 외부 클라이언트의 요청(Use Case)을 받아 도메인 객체를 로드하거나 저장하고, 도메인 객체의 메서드를 호출하는 등 도메인 계층을 조정하는 역할을 수행하라.21 이들은 인프라 계층의 리포지토리 인터페이스를 사용하여 도메인 객체를 로드하며, 핵심 비즈니스 로직은 순수하게 도메인 계층 내에서 실행되도록 위임해야 한다.

4. 아키텍처 통합 및 구현 환경을 조성하라

DDD를 성공적으로 구현하려면, 도메인 모델의 순수성을 지키기 위한 아키텍처적 통제가 필수적이다.

4.1 도메인 계층을 보호하는 아키텍처를 강제하라

계층형 아키텍처의 원칙을 적용하라: 소프트웨어 시스템을 여러 계층으로 구분하는 계층형 아키텍처를 도입하되 22, 의존성의 방향이 상위 계층에서 하위 계층을 향하도록 엄격히 강제하라.23 특히, 문제 해결에 필요한 도메인 지식을 담는 도메인 계층이 가장 중요한 계층이며, 이 계층이 자신보다 하위에 있는 인프라 계층에 직접 의존하는 구조를 허용하지 마라.23

의존성 역전 원칙(DIP)을 활용하라: 아키텍처는 기술 종속성으로부터 도메인을 보호하는 방패 역할을 해야 한다. 인프라 계층의 구현체는 반드시 도메인 계층에서 선언된 인터페이스(예: 리포지토리 인터페이스)를 구현하도록 강제하라.24 이 의존성 역전(Dependency Inversion)을 통해 도메인 중심의 설계가 기술적으로 보장되도록 하라.

헥사고날 아키텍처를 적극 도입하라: 헥사고날 아키텍처(Ports and Adapters)를 사용하여 비즈니스 로직을 모든 기술적 관심사(데이터베이스, 메시징 시스템, UI)로부터 완벽히 분리하라.25 이 아키텍처를 통해 도메인 모델은 중앙 코어로 남아 테스트 용이성과 이식성을 극대화할 수 있다.27 어댑터는 도메인 계층의 포트(인터페이스)를 구현하여 DB와의 통신 등 외부 작업을 수행하며, 도메인 모델의 순수성을 유지한다.26

4.2 마이크로서비스 경계를 DDD 원칙에 따라 설계하라

BC를 서비스의 경계로 삼으라: 마이크로서비스 아키텍처를 도입할 경우, 바운디드 컨텍스트를 마이크로서비스의 자연스러운 경계이자 후보로 활용하라.15 이는 도메인 모델의 독립성을 보장하고 서비스 간의 결합도를 낮춘다.28

애그리게이트 크기를 준수하라: 마이크로서비스의 크기 설계에 있어 엄격한 기준을 적용하라. 마이크로서비스는 애그리게이트보다 작아서는 안 되며, 바운디드 컨텍스트보다 커서도 안 된다는 원칙을 따르라.15 애그리게이트는 단일 트랜잭션을 책임지는 최소 단위이므로, 이보다 작게 서비스를 나누는 것은 데이터 무결성을 훼손할 위험이 있다.

도메인 엔티티와 영속성 엔티티를 엄격히 분리하라: DB와의 강한 결합을 피하기 위해 도메인 엔티티(비즈니스 규칙을 포함)와 영속성 엔티티(특정 ORM이나 DB 기술에 종속된 객체)를 엄연히 다른 개념으로 취급하고 분리하여 구현하라.26 도메인 엔티티는 비즈니스 규칙과 메서드를 포함해야 한다.27

5. DDD 도입 로드맵과 실질적인 운영 방안을 마련하라

5.1 이벤트 스토밍(Event Storming)을 통해 협력적 모델링을 정립하라

이해관계자 협력을 의무화하라: 이벤트 스토밍(Event Storming)은 DDD의 원칙을 실질적으로 적용하는 혁신적인 기법이다.11 이 세션을 정기적으로 진행하고, 개발자, 도메인 전문가, 비즈니스 리더 등 모든 이해관계자가 참여하도록 강제하라.11 도메인 이벤트를 중심으로 도메인의 상태 변화를 도출하고 시각화함으로써, 복잡한 시스템의 설계에 필요한 공동의 이해를 확보하라.11

도메인 이벤트 활용을 확대하라: 도메인 이벤트(Domain Event)는 시스템 내에서 발생한 중요한 사건을 나타내며, 이를 통해 도메인을 보다 명확히 모델링할 수 있다.8 도출된 이벤트들을 애그리게이트 간의 비동기 통신 및 분산 시스템 전반의 결과적 일관성(Eventual Consistency) 확보를 위한 핵심 메커니즘으로 적극 활용해야 한다.15

5.2 DDD 도입의 장점을 극대화하고, 레거시 시스템 전환에 활용하라

장점을 활용하여 유지보수성을 확보하라: DDD를 통해 도메인에 대한 높은 이해도를 바탕으로 설계가 이루어지면, 소프트웨어의 가독성 및 유지보수성이 현저히 향상된다.19 모듈화와 캡슐화를 통해 시스템의 유연성을 높이고 29, 이는 곧 SW Life Cycle 전반에 걸친 커뮤니케이션 비용 절감으로 이어진다.29

단점에 대응하라: DDD 도입에는 도메인 전문가의 필수 참여가 요구되며, 기존 도메인의 관행을 개선하는 데 조직적인 어려움이 수반될 수 있다.29 이러한 단점을 인지하고, 프로젝트 초기 단계에서부터 조직적 변화 관리와 함께 명확한 설계 표준을 확립하여 극복해야 한다.

레거시 전환에 DDD를 투입하라: 레거시 시스템의 전환은 리소스 부족과 고통을 동반하는 어려운 작업이다.30 오히려 이러한 상황에서 DDD를 도입하여 도메인에 대한 심층적인 이해를 이끌어내고, 레거시 시스템의 핵심 가치(도메인)를 재정의하라.30 마이크로서비스 아키텍처로의 전환 시, DDD의 개념(바운디드 컨텍스트, 애그리게이트)을 분해의 기준으로 활용함으로써 28, 낮은 결합도와 높은 응집도를 갖는 모듈화된 파이프라인 구조를 구축할 수 있다.28

6. 결론 및 행동 지침

도메인 주도 설계는 단순한 구현 방법론이 아니라, 복잡한 비즈니스 환경에서 소프트웨어 시스템의 구조적 무결성을 확보하기 위한 전략적 명령이다. 너희는 이 지침을 따라 설계의 중심을 기술이 아닌 도메인에 두어야 한다.

엄격한 DDD 구현을 위한 최종 명령:

  1. 모델의 순수성을 지켜라: 모든 기술적 상세로부터 도메인 모델을 분리하고, 헥사고날 아키텍처와 의존성 역전 원칙을 통해 도메인 계층을 방어하라.

  2. 애그리게이트를 신성시하라: 애그리게이트를 트랜잭션 경계 및 일관성 경계로 정의하고, 오직 루트를 통한 접근만을 허용하여 비즈니스 불변식을 원자적으로 유지하라.

  3. 유비쿼터스 언어를 표준화하라: 비즈니스 전문가와 협력하여 단일 언어를 정의하고, 이 언어를 코드, 문서, 의사소통 전반에 걸쳐 엄격히 준수하라.

  4. 전략적 경계를 명확히 하라: 바운디드 컨텍스트를 마이크로서비스의 경계로 활용하고, 컨텍스트 맵과 ACL 패턴을 통해 컨텍스트 간의 관계를 방어적으로 관리하라.

이 지침을 철저히 숙지하고 실천하여, 복잡하고 변화에 유연한 엔터프라이즈 시스템을 구축하라. 이는 너희 팀이 복잡한 비즈니스 환경에서 소프트웨어 개발의 통제력을 유지하는 유일한 길이다.

7. Works cited

  1. Domain-Driven Design (DDD): A Summary - Software Engineering - A Modern Approach, accessed September 28, 2025, https://softengbook.org/articles/ddd
  2. When do you use entities, value objects and aggregates (DDD)? - Stack Overflow, accessed September 28, 2025, https://stackoverflow.com/questions/77425208/when-do-you-use-entities-value-objects-and-aggregates-ddd
  3. Summary of the Domain Driven Design concepts | by robloxro - Medium, accessed September 28, 2025, https://medium.com/@ruxijitianu/summary-of-the-domain-driven-design-concepts-9dd1a6f90091
  4. Summary of #ddd by Eric Evans - GitHub Gist, accessed September 28, 2025, https://gist.github.com/danilobatistaqueiroz/f441e6a33e43b8bc47cf00d8eefd254b
  5. 도메인주도설계 첫걸음 #4(10~13장) - YouTube, accessed September 28, 2025, https://www.youtube.com/watch?v=m6GzdE6SHck
  6. DDD 설계 vs SQL 중심 설계 - 유원준의 개발로그 - 티스토리, accessed September 28, 2025, https://youwjune.tistory.com/38
  7. 전략적 설계의 Domain-Driven-Design - 코딩밥상 - 티스토리, accessed September 28, 2025, https://sheepseung.tistory.com/103
  8. DDD(Domain-Driven Design) - velog, accessed September 28, 2025, https://velog.io/@cks8483/DDDDomain-Driven-Design
  9. 백엔드 서버 아키텍처 — Domain Layer1. Domain Layer와 DDD | by Junha Baek - Medium, accessed September 28, 2025, https://medium.com/junhabaek/%EB%B0%B1%EC%97%94%EB%93%9C-%EC%84%9C%EB%B2%84-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-domain-layer1-domain-layer%EC%99%80-ddd-e97a7587a7b0
  10. accessed September 28, 2025, https://martinfowler.com/bliki/BoundedContext.html#:~:text=Bounded%20Context%20is%20a%20central,being%20explicit%20about%20their%20interrelationships.
  11. 이벤트스토밍이란? - msaschool - msaschool, accessed September 28, 2025, https://www.msaschool.io/operation/design/design-three/
  12. Bounded Context - Martin Fowler, accessed September 28, 2025, https://martinfowler.com/bliki/BoundedContext.html
  13. [DDD, 도메인 주도 개발] 9.도메인 모델과 바운디드 컨텍스트 (Bounded Context), accessed September 28, 2025, https://madini.tistory.com/35
  14. 도메인 주도 설계 핸드북 - 한걸음씩 천천히, accessed September 28, 2025, https://siyul-park.github.io/pattern/domain-driven-design-handbook/
  15. Using tactical DDD to design microservices - Azure Architecture Center - Microsoft Learn, accessed September 28, 2025, https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd
  16. Entity, Value Object, and Aggregate Root in Domain-Driven Design | by Kostiantyn Bilous | SharpAssembly | Medium, accessed September 28, 2025, https://medium.com/sharpassembly/entity-value-object-and-aggregate-root-in-domain-driven-design-0ce9402e4ad3
  17. DDD Beyond the Basics: Mastering Aggregate Design | by Mario …, accessed September 28, 2025, https://medium.com/ssense-tech/ddd-beyond-the-basics-mastering-aggregate-design-26591e218c8c
  18. [DDD] DDD(Domain Driven Design)에 대해 알아보자. - Peony의 기록 창고 - 티스토리, accessed September 28, 2025, https://myeongju00.tistory.com/76
  19. [Software Design] Domain-Driven Design 가볍게 살펴보기 | by Aiden - Medium, accessed September 28, 2025, https://medium.com/@ai-den/software-design-domain-driven-design-%EA%B0%80%EB%B3%8D%EA%B2%8C-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0-1d3f8fcd4fde
  20. DDD의 Repository Pattern은 왜 사용할까 - 나의 과거일지 - 티스토리, accessed September 28, 2025, https://jeongkyun-it.tistory.com/261
  21. 쉽게 말하는 DDD 서비스, 리포지토리 - velog, accessed September 28, 2025, https://velog.io/@jay/it-is-easy-ddd-service-repository
  22. Domain-Driven Design (DDD) - velog, accessed September 28, 2025, https://velog.io/@rl0425/Domain-Driven-Design-DDD
  23. [DDD] DDD와 아키텍처 - 루카쓰로그 v2.0, accessed September 28, 2025, https://lucathree.com/ddd-architecture
  24. 도메인 주도 개발 방법론(DDD)을 적용하여 3티어 아키텍처를 변경해보자, accessed September 28, 2025, https://upcurvewave.tistory.com/444
  25. [DDD 첫걸음] 2-4. 전술적 설계 - 아키텍처 패턴 - Jook의 Tech 생각, accessed September 28, 2025, https://share-factory.tistory.com/59
  26. hexagonal architecture?. 최근 DDD라는 말을 많이 들었다. DDD란 무엇일까 찾아보다 보니… | by hello | Medium, accessed September 28, 2025, https://medium.com/@hello-every-one/hexagonal-architecture-3729e9a9200b
  27. 헥사고날 아키텍처에서 유즈케이스 구현하기 - haon.blog, accessed September 28, 2025, https://haon.blog/haon/architecture/hexagonal/usecase/
  28. [논문 리뷰] Domain-Driven Design Representation of Monolith Candidate Decompositions Based on Entity Accesses - Moonlight, accessed September 28, 2025, https://www.themoonlight.io/ko/review/domain-driven-design-representation-of-monolith-candidate-decompositions-based-on-entity-accesses
  29. [SA] DDD (Domain Driven Design) - soultree - Inblog, accessed September 28, 2025, https://inblog.ai/soultree/sa-ddd-domain-driven-design-20237
  30. ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)2022 - YouTube, accessed September 28, 2025, https://m.youtube.com/watch?v=4QHvTeeTsj0