diff --git "a/hyoungJune/2023-11-24-\353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204 \354\262\253\352\261\270\354\235\214- \354\213\244\353\254\264\354\227\220\354\204\234\354\235\230 \353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204.md" "b/hyoungJune/2023-11-24-\353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204 \354\262\253\352\261\270\354\235\214- \354\213\244\353\254\264\354\227\220\354\204\234\354\235\230 \353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204.md"
new file mode 100644
index 00000000..03d3da7f
--- /dev/null
+++ "b/hyoungJune/2023-11-24-\353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204 \354\262\253\352\261\270\354\235\214- \354\213\244\353\254\264\354\227\220\354\204\234\354\235\230 \353\217\204\353\251\224\354\235\270 \354\243\274\353\217\204 \354\204\244\352\263\204.md"	
@@ -0,0 +1,64 @@
+> 해당 글은 도메인 주도 설계 첫걸음 (블라드 코노노프 지음, 김민석, 오창윤 옮김)을 정리한 글입니다.
+
+모든 DDD 패턴을 적용하여 실무에 도입하는 것은 실질적으로 불가능하다. 그러면 이상적이지 않은 환경에서 실제로 도메인 주도 설계 도구와 패턴을 적용하기 위해서는 어떻게 해야할까?
+
+## 전략적 분석
+실무에서 DDD를 도입하는 가장 좋은 출발점은 조직의 비즈니스 전략과 시스템 아키텍처의 현 상황을 이해하는데 시간을 투자하는 것이다.
+
+### 비즈니스 도메인 이해하기
+다음과 같이 회사의 비즈니스 도메인을 파악한다.
+- 조직의 비즈니스 도메인은 무엇인가?
+- 고객은 무엇인가?
+- 조직이 고객에게 제공하는 서비스 또는 가치는 무엇인가?
+- 경쟁 회사 또는 그들의 제품은 무엇인가?
+
+그 후 회사가 비즈니스 도메인에서 경쟁하기 위해 조직 단위들이 어떻게 협력하는지 조사한다.
+
+이 다음에 더 확대시켜서 경쟁 업체와 차별화 된 핵심 하위 도메인, 상용 솔루션이나 구독 서비스 또는 연동할 수 있는 오픈 소스를 사용 중인 하위 도메인, 그 다음 나머지 소프트웨어인 지원 하위 도메인을 찾는다.
+
+단, 모든 핵심 하위 도메인을 식별할 필요가 없기 때문에, 전체 구조를 식별하되, 개발 중인 소프트웨어 시스템과 가장 관련 있는 도메인에 더 주의해야한다.
+
+### 현재 설계 탐색
+도메인에 익숙해지면, 상위 수준 컴포넌트부터 도메인 주도 설계를 시작한다.
+
+### 전술적 설계 평가
+각 상위 수준 컴포넌트에 대해 비즈니스 하위 도메인에 포함되어 있는지, 어떤 시굴적 설계 의사결정을 내렸는지 평가한다.
+
+### 전략적 설계 평가
+상위 수준 컴포넌트에 대한 지식을 사용하여 현재 설계의 컨텍스트 맵을 차트로 표시한다. 이때 컨텍스트 맵은 컴포넌트가 바운디드 컨텍스트인 것처럼 표시한다.
+
+
+
+## 실무에 활용하는 도메인 주도 설계
+도메인 주도 설계를 조직 전략이 아닌 실무에 활용하는 전문 도구로 만들어, DDD에 대해 별로 신경 쓰지 않고 일상 업무에 DDD를 통합하도록 한다.
+
+## 유비쿼터스 언어
+
+유비쿼터스 언어는 도메인 지식 발견과 커뮤니케이션, 모델링에 필요하다. 이해관계자가 비즈니스 도메인을 언급할 때 혹은 이야기 할 때 사용하는 용어에 대해서 기울이고, 이를 용어집으로 만든다.
+
+일치하지 않는 용어인 경우에는 컨텍스트를 찾아 명시적으로 만들고, 의미가 같은 용어가 있다면 하나의 용어를 사용하도록 요청 해야 한다.
+
+가장 중요한 것은 코드와 모든 프로젝트 관련 의사소통에 유비쿼터스 언어를 사용하는 것이다.
+
+## 바운디드 컨텍스트
+
+분해 방법을 탐색할 때 바운디드 컨텍스트 패턴의 기반이 되는 원칙을 확인한다.
+ex) 
+- 모든 유스케이스에 대해 단일 모델 대신 문제 지향 모델을 설계하는 것이 더 나은 이유는 무엇일까? '올 인원' 솔루션은 거의 효과가 없기 때문이다.
+- 바운디드 컨텍스트가 충돌하는 모델을 관리할 수 없는 이유는 무엇일까? 인지 부하가 증가하고 솔루션이 복잡해지기 때문이다.
+- 여러 팀이 동일한 코드베이스에서 작업하는 것이 왜 나쁜 생각일까? 팀 간의 마찰이 발생하고 협업에 방해되기 때문이다.
+
+등, 바운디드 컨텍스트 통합 패턴에 대해 동일한 추론을 사용하여 문제를 이해시킨다.
+
+## 전술적 설계 의사결정
+
+전술적 설계 패턴에 대해 논의할 때 'DDD 책에서 그렇게 말하니까 여기에 애그리게이트를 사용하자!' 라는 논리로 다가가지 말아야 한다.
+
+ex)
+- 명시적 트랜잭션 경계가 중요한 이유는 무엇일까? 데이터의 일관성을 보호하기 위해서다.
+- 왜 우리는 작은 애그리게이트 경계를 위해 노력해야 할까? 넓은 트랜잭션 범위는 애그리게이트의 복잡성을 증가시키고 성능에 부정적인 영향을 주기 때문이다.
+- 이벤트 소싱 대신에 이벤트를 로그 파일에 기록할 수 없는 이유는 무엇일까? 장기적으로 데이터 일관성을 보장되지 않기 때문이다.
+
+## 요약
+요약하자면, DDD가 조직에서 널리 채택되지 않은 경우에도 도메인 주도 설계 도구를 사용하여, 각 패턴 뒤에 있는 논리와 원칙으로 사용하라는 것이다.
+