diff --git "a/chap11/\354\206\241\354\230\201\353\257\274.md" "b/chap11/\354\206\241\354\230\201\353\257\274.md"
new file mode 100644
index 0000000..446a5c8
--- /dev/null
+++ "b/chap11/\354\206\241\354\230\201\353\257\274.md"
@@ -0,0 +1,36 @@
+## 11-1. 단일 모델의 단점
+- 단일 모델의 단점
+  - 여러 애그리거트의 데이터가 필요할 때, 식별자를 이용한 참조시 JPA 쿼리최적화 사용하기 어려움
+    - 여기서 식별자를 사용한다는 뜻은, id만을 필드로 두고 재조회 하는 얘기임.
+    - 예를 들어, 1:N 관계가 있을때 둘다 필요하다는 가정 하에 한 쿼리로 조회에 필요한 모든걸 가져올 수 없음
+  - 식별자가 아닌 직접 참조시에도 (ex. @ManyToOne) 특성에 따라 이거로딩, 레이지로딩 등으로 처리해야함.
+  - 위와같이 단일 도메인 모델로 모든것을 하기에는 구현이 복잡해지거나 성능이 떨어짐.
+
+## 11-2. CQRS
+- 시스템이 제공하는 기능은 크게 두가지로 나뉨
+  - 상태 변경 (Command)
+  - 상태 정보 조회 (Query)
+- 보통 모델의 관점에서, 상태 변경은 하나의 애그리거트만 건드리는데, 조회 시에는 일반적으로 여러 애그리거트 필요
+- 즉, 상태 변경 명령용 모델과 상태 정보 조회용 모델을 분리하자! 라는 취지
+- 이떄, 명령 모델은 JPA를 쓰고, 조회 모델은 mybatis(책피셜), querydsl(내피셜)등으로 만들 수 있음.
+- 조회 모델은 간단해서 application 레이어 없이 바로 DAO를 컨트롤러에서 실행해도 무방
+  - 물론 그 데이터를 어떻게 재가공 하는 로직이 들어가면, 서비스 필요
+- 뿐만 아니라 명령모델과 조회모델이 서로다른 데이터 젖아소(rdbms, nosql 등)을 사용할 수 있다.
+
+### 11-2-1. 웹과 CQRS
+- 웹은 일반적으로 상태를 조회하는(Query) 경우가 더 많다.
+- 트래픽이 높은 서비스 만드는 개밡팀은 조회 속도를 높이기 위한 다양한 기법을 사용한다
+  - 쿼리 최적화로 쿼리 실행 속도를 높이며
+  - 메모리에 조회 데이터를 캐싱해 응답 속도를 높인다
+- 결국 이런 다양한 기법은 CQRS를 적용하는 등의 효과를 낸다.
+- 대규모 서비스는 알게모르게 CQRS를 적용하고 있을 수 있다.
+
+### 11-2-2. CQRS의 장단점
+- 장점
+  - 명령 모델 구현시 도메인 자체에 집중할 수 있다.
+  - 명령 모델에서 조회 관련 로직이 사라져 복잡도가 낮아진다
+  - 조회 성능을 향상시키는데 유리하다
+- 단점
+  - 구현이 복잡해진다
+  - 더 많은 구현 기술이 필요하다. (필요에 따라)
+- 즉 도메인이 복잡하지 않은데 도입하는것은 유지 비용을 높이는데 이점은 없다.