diff --git "a/chap09/\354\206\241\354\230\201\353\257\274.md" "b/chap09/\354\206\241\354\230\201\353\257\274.md"
new file mode 100644
index 0000000..12ee218
--- /dev/null
+++ "b/chap09/\354\206\241\354\230\201\353\257\274.md"
@@ -0,0 +1,41 @@
+# DDD 9장
+
+### 9-1. 도메인 모델과 경계
+- 한개의 모델로 모든 하위 도메인을 표현할 수는 없다.
+- 하위 도메인마다 올바른 도메인 모델을 만들어야 한다.
+- 이 모델들은 명확한 경계를 가져야 한다.
+- 위와같이 문맥에 따른 경계를 "바운디드 컨텍스트"라고 한다.
+
+### 9-2. 바운디드 컨텍스트
+- 한개의 바운디드 컨텍스트는 논리적으로 한개의 모델을 갖는다.
+- 경우에 따라(팀 구분 등) 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
+- 이럴때 주의할 점은 하위 모델들이 섞이지 않도록 해야한다.
+- 이럴 때 각 하위 모델(도메인)들이 각 패키지를 가지게 하면, 각 도메인별로 바운디드 컨텍스트를 가지게 할 수 있다.
+- 같은 의미를 나타내는 개체이더라도 각 바운디드 컨텍스트가 갖는 도메인 모델은 다를 수 있다.
+
+### 9-3. 바운디드 컨텍스트 구현
+- 바운디드 컨텍스트는 도메인 기능 서빙에 필요한 모든 레이어를 구현한다.
+- 각 바운디드 컨텍스트는 다른 아키텍쳐(MVC, Clean Architecture 등)로 설계할 수 있다.
+- 구현 기술 역시 컨텍스트별로 다른 기술(WebMVC, Netty, MySQL, Redis)를 쓸 수 있다.
+- 무조건 바운디드 컨텍스트가 UI계층을 가질 필요는 없다. (ui 서버를 두거나, json만 응답하거나)
+
+### 9-4. 바운디드 컨텍스트 간 통합
+- 여러 바운디드 컨텍스트의 통합이 필요한 경우가 있다. (카탈로그-추천 관계)
+- 각 도메인 모델은 다를 것이다. 이때, 카탈로그의 모델을 기반으로 하는 상품 추천 기능을 필요로 할 것이다.
+- 그걸 도메인 클래스로 만들고, 실제 경계간 통합 기술(restapi등)은 인프라 영역에 구현한다.
+- 위와같이 직접 통합하는 방법보다, 메세징 큐 같은걸로 간접 통합을 할 수도 있다.
+- 뭐 카탈로그 생성시 큐로 밀어넣고, 추천 시스템은 그걸 빨아서 추천 데이터를 업데이트 하는 식
+
+### 9-5. 바운디드 컨텍스트 간 관계
+- 의존 관계상 상류-하류 관계가 있을텐데, 서로간 잘 합의를 하고 개발을 해야 꼬이지 않는다.
+- 상류-하류에서 하류가 여러개일 경우 여러 요구사항을 수용할 수 있는 API를 만들고 공개 호스트 서비스 형태로 구현할 수 있다.
+- 상류 팀은 아래 모든 요구를 수용하는 단일 API를 만들어 공개하고, 하류 팀은 이를 이용해 구현한다.
+- 하류 팀이 상류 팀 도메인 모델에 영향을 받지 않으려면, 이를 위한 "안티코럽션 계층"이 필요하다.
+- 이는 위의 서비스 만들고 -> 인프라 계층에서 구현 하면서 모델 변환 처리를 통해 막을 수 있다.
+- 두 바운디드 컨텍스트가 같은 모델을 공유할 경우 공유 커널(그냥 같은 도메인 모델 쓰기)를 쓸수 있지만, 밀접한 관계를 형성하지 못하면 부채가 될 수 있다.
+- 독립 방식 관계는... 그냥 서로 통합하지 않겠다는 거다. 뭐 커머스-erp 연동을 시스템적으로 하는게 아니라 직원한테 이거 밀어넣어주세요~ 시키는거다.
+
+### 9-6. 컨텍스트 맵
+- 서로 바운디드 컨텍스트간의 관계를 표시한 지도이다.
+- OHS(오픈 호스트 서비스)와 ACL(안티코럽션 계층)을 나타내며 연결한다.
+- 따로 규칙이 있진 않고, 잘 나타내게 그리면 된다.
\ No newline at end of file