llm-wiki/raw/official-docs/domain-event-fowler-eaa.md

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

title	source_type	url	archive_url	related_branches	related_projects	tags	created	last_reviewed
Martin Fowler — Domain Event (EAA Dev catalog)	official-doc	https://martinfowler.com/eaaDev/DomainEvent.html		feature-domain-event-outbox-contract	ca-skeleton	official-doc ca-outbox-pattern domain-event ddd fowler backend messaging	2026-06-11	2026-06-11

Martin Fowler — Domain Event (EAA Dev catalog)

Layer: raw/official-docs/ — Martin Fowler EAA Dev catalog "DomainEvent" (2005-12-12) verbatim 발췌. D1 ("domain event 는 transport detail 을 모름") 의 정의 근거: domain event 의 본질이 도메인에서 일어난 사실의 기록이며 transport/infrastructure 가 정의에 포함되지 않음을 보인다. Evidence strength: engineering-blog — Fowler EAA Dev 는 개인 패턴 카탈로그 (draft 상태 명시). official-vendor-doc / official-standard 아님. D1 을 공식 best practice 로 격상하려면 Eric Evans DDD 원전 등 별도 official raw 필요.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-domain-event-outbox-contract	D1 — "domain event 는 transport detail (Kafka topic, HTTP endpoint, Slack channel) 을 모름" — domain event 의 정의가 도메인 사실의 기록(record of something that happened in the domain)이며 transport/infrastructure 가 정의에 포함되지 않음을 보이는 근거.

출처 / Source

• 원본 URL: https://martinfowler.com/eaaDev/DomainEvent.html
• 아카이브 URL: (미수집 — archive.org 스냅샷 별도 확보 권장)
• 저자 / 조직: Martin Fowler
• 발행일: 2005-12-12
• 마지막 확인일: 2026-06-11

왜 저장했는지 / Why archived

feature-domain-event-outbox-contract D1 은 "domain event 가 Kafka topic / HTTP endpoint 등 transport detail 을 포함해서는 안 된다"는 금지 결정이지만, Decision Evidence Map 에서 UNSUPPORTED_DECISION 라벨이 붙어 있었다. 본 자료는 Fowler 의 Domain Event 정의("captures the memory of something interesting which affects the domain")와 "two-layer 구조에서 second layer 는 실제 input source 를 모른다"는 설명이 D1 의 정의 근거가 됨을 보이기 위해 수집한다. 단, Fowler 원문이 "transport independence" 를 직접 claim 하지는 않으므로 해석 범위는 Usage Boundaries 참조.

핵심 인용 / Key quotes (verbatim, 3~5문장)

[§subtitle / tagline] "Captures the memory of something interesting which affects the domain"

[§How it Works — opening] "The essence of a Domain Event is that you use it to capture things that can trigger a change to the state of the application you are developing. These event objects are then processed to cause changes to the system, and stored to provide an Audit Log."

[§How it Works — two-layer] "In this stream the first input layer of the system takes no action to the stimulus other than to create and log an event. The second layer can then be ignorant of the actual input source, it just reacts to the event and processes it."

[§How it Works — immutability] "I characterize the data on a Domain Event as immutable source data that captures what the event is about and mutable processing data that records what the system does in response to it."

[§How it Works — time] "Events are about something happening at a point in time, so it's natural for events to contain time information. When doing this it's important to consider two Time Point that could be stored with the event: the time the event occurred in the world and the time the event was noticed."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리. 내 프로젝트 해석은 Usage Boundaries 에만 기술.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
DOMAIN-EVT-FOWLER-C1	Domain Event 의 목적은 도메인에 영향을 미친 흥미로운 것의 기억(memory)을 포착하는 것이다	[§tagline] "Captures the memory of something interesting which affects the domain"	engineering-blog	Fowler EAA Dev 패턴 카탈로그에서의 Domain Event 정의	"transport detail 포함 금지" 를 직접 명시하지 않음. Eric Evans DDD 원전과 같은 공식 표준은 아님
DOMAIN-EVT-FOWLER-C2	Domain Event 의 본질은 application state 변경을 유발하는 것들을 포착하는 데 있으며, 이벤트 객체는 처리된 후 Audit Log 로 저장된다	[§How it Works] "The essence of a Domain Event is that you use it to capture things that can trigger a change to the state of the application you are developing. These event objects are then processed to cause changes to the system, and stored to provide an Audit Log."	engineering-blog	Event Sourcing 이나 Outbox 패턴의 정의 레이어 논거로 사용 가능	"Kafka topic 또는 HTTP endpoint 와 결합해야 한다/하지 말아야 한다"는 직접 진술 없음
DOMAIN-EVT-FOWLER-C3	two-layer 구조에서 두 번째 레이어는 실제 input source 를 모른 채 이벤트에 반응한다	[§How it Works] "The second layer can then be ignorant of the actual input source, it just reacts to the event and processes it."	engineering-blog	이벤트 처리 레이어의 input-source 독립성 논거	이 문장은 event processor 의 input 추상화를 설명하는 것이지, domain event 객체 자체가 transport detail 을 배제해야 한다는 prescriptive claim 이 아님
DOMAIN-EVT-FOWLER-C4	Domain Event 의 source data 는 불변(immutable)이며, 이벤트가 무엇에 관한 것인지를 포착하는 불변 source data 와 시스템 반응을 기록하는 mutable processing data 로 특성화된다	[§How it Works] "I characterize the data on a Domain Event as immutable source data that captures what the event is about and mutable processing data that records what the system does in response to it."	engineering-blog	event payload 설계 시 불변성 및 데이터 분리 기준	"불변성이 transport independence 를 보장한다"는 논리적 도약은 이 자료가 직접 지지하지 않음
DOMAIN-EVT-FOWLER-C5	이벤트는 특정 시점에 발생한 것이므로 두 가지 Time Point — 세계에서 이벤트가 발생한 시간(occurred)과 인지된 시간(noticed) — 를 저장할지 고려해야 한다	[§How it Works] "Events are about something happening at a point in time, so it's natural for events to contain time information. When doing this it's important to consider two Time Point that could be stored with the event: the time the event occurred in the world and the time the event was noticed."	engineering-blog	Domain Event payload 의 timestamp 필드 설계 (occurredAt vs notifiedAt)	"어떤 timestamp 필드명이 표준인가"를 prescribe 하지 않음. ca-tmpl 의 occurredAt 필드명은 내부 결정

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • DOMAIN-EVT-FOWLER-C1: Domain Event = "도메인에서 일어난 흥미로운 것의 기억" 이라는 Fowler 의 정의
  • DOMAIN-EVT-FOWLER-C2: Domain Event 는 application state 변경 유발 + Audit Log 저장 목적의 객체라는 정의
  • DOMAIN-EVT-FOWLER-C3: 이벤트 처리 두 번째 레이어가 실제 input source 에 무관하게 동작한다는 설명 (input abstraction)
  • DOMAIN-EVT-FOWLER-C4: Domain Event source data 의 불변성 원칙
  • DOMAIN-EVT-FOWLER-C5: occurredAt (occurred) / noticedAt (noticed) 두 가지 Time Point 고려 필요성
• 이 자료가 증명하지 않는 것:
  • "domain event 가 transport detail 을 포함해서는 안 된다"는 prescriptive 규칙을 원문이 직접 claim 하지 않는다. D1 의 "transport detail 을 모름"은 DOMAIN-EVT-FOWLER-C1~C3 의 정의로부터 도출된 해석 이지, Fowler 원문의 verbatim 진술이 아니다. transport-independence 는 해석이지 직접 claim 이 아님을 Usage Boundary 에 명시한다.
  • Fowler EAA Dev 는 개인 패턴 카탈로그이며, 원문 자체에 "this material is very much in draft form" 이라고 명시되어 있음. Eric Evans DDD, Vaughn Vernon IDDD 같은 공식 원전과 동등한 강도로 인용할 수 없다.
  • DOMAIN-EVT-FOWLER-C3 의 "second layer ignorant of input source" 는 event processor / handler 의 아키텍처 layering 을 설명하는 것이지, domain event 클래스의 필드 구성에 대한 규칙이 아니다.
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • D1 을 UNSUPPORTED_DECISION 에서 engineering-blog 강도 이상으로 격상하려면 Eric Evans "Domain-Driven Design" 또는 Vaughn Vernon "Implementing Domain-Driven Design" 의 domain event 정의 raw 별도 수집 필요.
  • DOMAIN-EVT-FOWLER-C5 의 Time Point 두 가지를 ca-tmpl outbox table 필드 (occurredAt + 별도 relayedAt 등)로 매핑하는 결정은 내부 결정이며 이 raw 가 직접 prescribe 하지 않음.

메모 / Notes

• Fowler 원문 첫 문단: "this material is very much in draft form and I won't be doing any corrections or updates" — 2005년 작성 이후 갱신 없음. engineering-blog strength 이상의 인용 금지.
• DOMAIN-EVT-FOWLER-C3 ("second layer ignorant of input source") 는 D1 의 간접 지지 근거로 사용 가능하나, 그 자체가 "transport detail 포함 금지" prescriptive 규칙은 아님. branch-note Decision Evidence Map 에서 이 distinction 을 명시해야 함.
• 추가로 봐야 할 동일 출처 페이지: https://martinfowler.com/eaaDev/EventSourcing.html (EventSourcing 패턴, DOMAIN-EVT-FOWLER-C2 의 "Event Sourcing" 언급과 연결)

Related / 관련

• 같은 주제 다른 official-doc / company-tech-blog:
  • raw/official-docs/domain-fowler-anemic-vs-rich-model — 동일 저자, rich domain model 관련
  • raw/official-docs/microservices-io-transactional-outbox — outbox 패턴 카탈로그 (Chris Richardson)
  • raw/official-docs/outbox-debezium-official-docs — Debezium outbox SMT (transport layer 측)
• 이 자료를 인용한 wiki 요약: (생성 시 추가)