Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

11 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title

source_type

url

archive_url

status

confidence

Vaughn Vernon — Effective Aggregate Design (Implementing DDD)

Layer: raw/official-docs/ — Vaughn Vernon "Effective Aggregate Design" (2011 paper, 3-part PDF on dddcommunity.org) + "Implementing Domain-Driven Design" (Addison-Wesley 2013) Ch.10 발췌. ca-tmpl 의 aggregate root 가시성 / VO invariant / ORM-friendly constructor 결정의 1차 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-domain-modeling-guardrails	aggregate root mutator 가시성 = package-private/protected, VO private constructor + invariant in constructor 채택
raw/branch-notes/feature-architecture-enforcement-rules	"외부에서 entity 의 setter 직접 호출 금지" ArchUnit 룰의 근거 (mutation = root method only)
raw/branch-notes/feature-skeleton-package-blueprint-contract	feature 패키지 내 aggregate 경계 = 하나의 root + 내부 entity/VO 묶음 구조
raw/branch-notes/feature-domain-feature-onboarding-contract	신규 도메인 추가 시 "small aggregate" 가이드 — 거대 aggregate 방지 체크

컨텍스트 / 왜 저장했는지

ca-tmpl 결정: "aggregate root mutator package-private/protected" + "VO private constructor + invariant". 이 결정의 출처. Vernon은 DDD 커뮤니티에서 Eric Evans 다음으로 인용되는 표준 reference.

출처 / Source

원본 URL (landing 페이지): https://www.dddcommunity.org/library/vernon_2011/ — Vaughn Vernon "Effective Aggregate Design" 3-part PDF 시리즈 메타데이터 페이지
원본 PDF: 위 페이지에서 Part I/II/III 링크 (직접 PDF 본문 verbatim 발췌 미수집 — 본 raw 의 4 rules 인용은 통상적으로 회자되는 요약 wording 임)
보조: "Implementing Domain-Driven Design" (Addison-Wesley, 2013, Ch. 10 Aggregates) — 도서 본문, URL 없음
보조: DDD-Crew aggregate patterns — https://github.com/ddd-crew
저자/조직: Vaughn Vernon
발행일: 2011-10-01 (paper, dddcommunity.org sponsor: Domain Language, Inc.), 2013 (IDDD book)
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes

[§dddcommunity 페이지 메타] "Vaughn's concrete rules spell out the current consensus view of DDD leaders" — 본 URL 페이지 본문은 PDF 링크 + 저자 소개만 노출, 4 rules 본문 자체는 PDF 안에 있음.

다음은 IDDD 책 Ch.10 (Aggregates) 와 Effective Aggregate Design paper 에서 통상적으로 회자되는 4 rules 의 요약 wording. PDF 원전 직접 verbatim 발췌 아님 — needs-confirmation 으로 분류.

[§Rule 1, paraphrased] "Model True Invariants in Consistency Boundaries. An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. A properly designed aggregate is one that can be modified in any way required by the business with its invariants completely consistent within a single transaction."

[§Rule 2, paraphrased] "Design Small Aggregates. Large clusters of objects in one aggregate may be expedient when first conceived, but they will not perform well and will not scale."

[§Rule 3, paraphrased] "Reference Other Aggregates by Identity. Storing references to other aggregates by identity (not by direct object reference) keeps aggregates small, supports eventual consistency between aggregates, and avoids the temptation to modify multiple aggregates in a single transaction."

[§Rule 4, paraphrased] "Update Other Aggregates Using Eventual Consistency. When you find yourself wanting to modify multiple aggregates in one transaction, reconsider whether they should be a single aggregate, or whether eventual consistency (via domain events) is acceptable."

[§IDDD Ch.10, paraphrased] "Make aggregate roots manage internal mutation. Internal entities are mutated only through methods on the root. ORM-friendly constructors should be package-private or protected to prevent application code from bypassing invariants."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
VERNON-AGG-C1	dddcommunity.org Vernon 2011 페이지에 "Effective Aggregate Design" 3-part PDF 시리즈가 호스팅되고, Vernon 의 규칙들이 DDD 리더들의 합의 견해 (current consensus) 로 소개됨	[§dddcommunity 페이지 메타] "Vaughn's concrete rules spell out the current consensus view of DDD leaders"	`official-reference`	DDD aggregate 설계 reference 출처 인증	4 rules 의 정확한 wording 이 본 URL HTML 에 있다는 뜻은 아님 — 본문은 PDF
VERNON-AGG-C2	Aggregate 의 invariant 는 단일 transaction 내 에서 완전히 일관되어야 한다 (Rule 1, Consistency Boundary)	[§Rule 1, paraphrased] "modified in any way required by the business with its invariants completely consistent within a single transaction"	`needs-confirmation` (paraphrased — PDF 원전 verbatim 확인 필요)	DDD-style aggregate 채택 프로젝트	"transaction 경계 = DB transaction" 이라는 뜻은 아님 — Vernon 자신이 동일 글에서 eventual consistency 도 정의
VERNON-AGG-C3	Aggregate 는 작게 설계해야 한다 — 큰 aggregate 는 성능/확장에 문제를 일으킨다 (Rule 2, Small Aggregates)	[§Rule 2, paraphrased] "Large clusters...will not perform well and will not scale"	`needs-confirmation` (paraphrased)	모든 aggregate 설계 결정	정확한 크기 임계 (예: entity 수 ≤ N) 의 정량 기준은 본 자료 없음
VERNON-AGG-C4	다른 aggregate 는 direct reference 가 아닌 identity 로만 참조해야 한다 (Rule 3)	[§Rule 3, paraphrased] "Reference Other Aggregates by Identity...keeps aggregates small, supports eventual consistency"	`needs-confirmation` (paraphrased)	inter-aggregate 관계 모델링	JPA `@ManyToOne` 자체가 금지된다는 뜻은 아님 (Vernon 도 trade-off 인정) — 별도 ORM 매핑 결정 필요
VERNON-AGG-C5	여러 aggregate 의 동시 변경이 필요하면 단일 aggregate 로 재설계하거나 domain event 기반 eventual consistency 로 처리해야 한다 (Rule 4)	[§Rule 4, paraphrased] "use...eventual consistency (via domain events)"	`needs-confirmation` (paraphrased)	multi-aggregate update 시나리오	event broker / outbox 의 구체 구현은 본 글 범위 밖 (별도 outbox contract 결정)
VERNON-AGG-C6	IDDD Ch.10 은 ORM-friendly constructor 가시성을 package-private/protected 로 두어 application layer 가 invariant 를 우회하지 못하게 하는 패턴을 제시	[§IDDD Ch.10, paraphrased] "ORM-friendly constructors should be package-private or protected to prevent application code from bypassing invariants"	`needs-confirmation` (도서 인용 — 페이지/문단 미지정)	JPA + DDD aggregate 결합 프로젝트	Spring/Kotlin/Scala 특유의 추가 가시성 제어 (internal, sealed 등) 는 본 글 범위 밖

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- VERNON-AGG-C1: dddcommunity.org 가 Vernon paper 의 공식 reference host 라는 사실
이 자료가 증명하지 않는 것 (현재 단계):
- 4 rules 의 정확한 verbatim wording — VERNON-AGG-C2~C5 는 PDF 본문 직접 확인 전까지 paraphrased / needs-confirmation
- IDDD 책 Ch.10 의 ORM-friendly constructor 문구 — VERNON-AGG-C6 도 도서 원전 페이지 확인 필요
- ca-tmpl 의 "domain logger ban" 결정 — Vernon 자체는 logger 금지 명시 안 함, "domain knows nothing about infrastructure" 에서 간접 도출 (별도 근거 필요)
- "JPA annotation 을 domain class 에 두는 것" 의 옳고 그름 — Vernon IDDD 자체는 양쪽 예시 모두 제공
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- PDF Part I/II/III 본문에서 4 rules 의 정확한 chapter 제목과 verbatim 문장 추출 (현재는 paraphrased)
- "package-private" 이 Java 외 다른 JVM 언어 (Kotlin internal, Scala private[package]) 에 어떻게 매핑되는지
- ca-tmpl 의 "Option A: domain 외부 매핑 (MapStruct/JpaEntity 분리)" 이 Vernon Option B (JPA annotation on domain) 대비 더 안전하다는 근거 — 본 자료로 증명 불가, 별도 결정 라인 필요

메모 / Notes (내 프로젝트 해석 — 자료 직접 인용 아님)

ca-tmpl 결정과의 매핑:
- "VO with private constructor + invariant in constructor" = Vernon's "fail-fast invariant" 원칙. Vernon은 VO를 immutable side-effect-free로 정의.
- "aggregate root mutator package-private/protected" = IDDD Ch.10의 "ORM-friendly constructor" 패턴. JPA가 reflection으로 객체 생성하려면 no-arg constructor가 필요한데, public이 되면 application layer가 invariant를 우회 가능. package-private/protected로 풀어줌.
- "domain logger ban" = Vernon의 "domain은 transport-free" 원칙과 호환. Vernon이 명시적으로 "logger 금지"라고 쓰지는 않았으나 "domain knows nothing about infrastructure"에서 도출 가능.
ca-tmpl 결정 중 "ORM 외부 매핑"의 의미:
- Option A (ca-tmpl 채택): domain class에 JPA annotation 없이, MapStruct 또는 별도 JpaEntity로 외부 매핑.
- Option B (Vernon 도서 예시): domain class에 JPA annotation을 두되 mutator를 package-private 화. 더 간결하지만 domain이 JPA를 import함 → ca-tmpl의 "forbidden import" rule 위배.
ca-tmpl이 Option A를 택한 이유는 본 raw에 명시되지 않음 (별도 결정 라인 필요).
출처 신뢰도: dddcommunity.org 호스팅 paper + 저자 도서 — DDD 영역에서 reference 표준이나, PDF 본문 verbatim 미확보 → C2~C6 은 needs-confirmation 유지. URL 자체는 official-reference (community-curated official library).

11 KiB Raw Blame History