오타 수정

network/그림으로배우는_HTTP.md

@@ -108,16 +108,16 @@ Options 메서드는 리퀘스트 URI로 지정한 리소스가 제공하고 있
 ### Trace: 경로 조사
 TRACE 메서드는 Web 서버에서 접속해서 **자신에게 통신을 되돌려받는 루프백(Loop back)을 발생 시킵니다.**
 
-리퀘스트를 보낼떄 `Max-Forwards` 라는 해더 필드에 수치를 포함시켜 서버를 통과할 때 마다 그 수치를 줄여갑니다. 수치가 0이 되는 곳을 끝으로, 리퀘스트를 마지막으로 수신한 곳에서 상태 코드 200 OK 리스폰스를 돠돌려 줍니다.
+리퀘스트를 보낼때 `Max-Forwards` 라는 해더 필드에 수치를 포함시켜 서버를 통과할 때 마다 그 수치를 줄여갑니다. 수치가 0이 되는 곳을 끝으로, 리퀘스트를 마지막으로 수신한 곳에서 상태 코드 200 OK 리스폰스를 돠돌려 줍니다.
 
 클라이언트는 TRACE 메서드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지를 등을 조사할 수 있습니다.
 
-이것은 프록시 등을 중계하여 오리진 서버에 접소갛ㄹ 때 그 동작을 확인 하기 위해서 사용되고 있습니다. 다만, TRACE 메서드는 거의 사용되지 않는데다 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제도 있기 떄문에 보통은 사용되고 있지 않습니다.
+이것은 프록시 등을 중계하여 오리진 서버에 접소갛ㄹ 때 그 동작을 확인 하기 위해서 사용되고 있습니다. 다만, TRACE 메서드는 거의 사용되지 않는데다 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제도 있기 때문에 보통은 사용되고 있지 않습니다.
 
 ## 지속 연결로 접속량을 절약
 ![](../assets/http-connection-flow.jpg)
 
-HTTP 초기 버전에서는 **HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료**를 할 필요가 있었습니다. 하지만 다량의 이미지를 포함한 문서 등이 늘어 남아 따라서 리퀘스트를 보낼 떄마다 매번 TCP 연결과 종료를 하게 되는 쓸모 없는 일이 발생되어 통신량이 늘어나게 됩니다.
+HTTP 초기 버전에서는 **HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료**를 할 필요가 있었습니다. 하지만 다량의 이미지를 포함한 문서 등이 늘어 남아 따라서 리퀘스트를 보낼 때마다 매번 TCP 연결과 종료를 하게 되는 쓸모 없는 일이 발생되어 통신량이 늘어나게 됩니다.
 
 
 ### 지속 연결
@@ -282,12 +282,12 @@ HTTP /1.1 에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실
 
 ![](../assets/http-proxy.jpg)
 
-HTTP 통신을 할 떄, 프록시 서버를 여러 대 경유하는 것도 가능합니다. 체인과 같이 여러 대 경유해서 리퀘스트랑 리스폰스ㅡㄹㄹ 중계해 갑니다. 중계할 때에는 Via 헤더 필드에 경유한 호스트 정보를 추가해야 합니다.
+HTTP 통신을 할 때, 프록시 서버를 여러 대 경유하는 것도 가능합니다. 체인과 같이 여러 대 경유해서 리퀘스트랑 리스폰스ㅡㄹㄹ 중계해 갑니다. 중계할 때에는 Via 헤더 필드에 경유한 호스트 정보를 추가해야 합니다.
 
 캐시를 사용해서 네티워크 대역 등을 효율적으로 사용하는 것과 조직 내에 특정 웹 사이트에 대한 엑세스 재한, 액새스 로그를 획득하는 경책을 철저하게 지키려는 목적으로 사용되는 경우도 있습니다.
 
 #### 캐싱 프록시
-프록시로 리스폰스를 중계하는 떄에는 프록시 서버 상에 리소스를 캐시를 보존해 두는 타입의 프록시입니다.
+프록시로 리스폰스를 중계하는 때에는 프록시 서버 상에 리소스를 캐시를 보존해 두는 타입의 프록시입니다.
 
 프록시에 다시 같은 리소스에 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로 되돌려주는 것이 있습니다.
 

도서/도메인 주도 설계란 무엇인가.md

@@ -3,7 +3,7 @@
 # 도메인 주도 설계
 
 ## 계층형 아키텍처
-소프트웨어 애플리케이션을 만들떄, 응용 시스템의 상당 부분은 도메인과 직접적인 관련이 없다. 오히려 인프라스트럭처나 소프트웨어를 지원하는 제반 환경에 대한 것들이 소픝웨어의 큰 부분을 차지한다. 도메인이 다른 부분에 비해 상대적으로 작은 부분이 되기도하다.
+소프트웨어 애플리케이션을 만들때, 응용 시스템의 상당 부분은 도메인과 직접적인 관련이 없다. 오히려 인프라스트럭처나 소프트웨어를 지원하는 제반 환경에 대한 것들이 소픝웨어의 큰 부분을 차지한다. 도메인이 다른 부분에 비해 상대적으로 작은 부분이 되기도하다.
 
 ![](../assets/ddd-layer-architecture.jpg)
 
@@ -34,7 +34,7 @@
 ## 서비스
 우리가 도메인을 분석하여 모델을 구성하는 주요 객체를 정의하려고 할 때 도메인의 어떤 부분들은 객체로 쉽게 매핑될 수 없다는 사실을 발견하게 된다. 객체는 속성과 객체가 관리하는 내부 상태 정보와 밖으로 드러나느 행위를 가지고 있다. 유비쿼터스 언어를 정의할 때 도메인의 핵심 개념이 나타나면 명사는 쉽게 객체로 매핑할 수 있다. 명사와 연건되어 해당 객체의 행위를 나타내는 동사는 보통 객체의 행위 부분이 된다. 그러나 **도메인의 행위 가운데 어떤 행동이나 일부 동사는 어느 객체어도 속하지 않는다.** 그들은 도메인의 아주 중요한 행동이어서 가볍게 무시하거나 간단히 하나의 엔티티 혹은 값 객체에 집어넣어 버릴 수도 없다. **이러한 행위를 어떤 객체에 추가하면 그 객체에 속하지도 않은 기능을 추가하는 셈이라 결과적으로 그 객체를 망칠 수 있다.**
 
-**그럼에도 불구하고, 객체지향 언어를 사용할 때에는, 우리는 객체를 행위를 포괄하는 용도로 사용해야만 한다.** 그 기능을 그 제차로만 따로 떄어놓고 선언할 수는 없다. **행위는 한 객체에 포함되어야만 한다.** 때떄로 이런 유형의 행위가 여러개의 서로 다른 클래스의 객체에 걸처서 동작하기도한다. 
+**그럼에도 불구하고, 객체지향 언어를 사용할 때에는, 우리는 객체를 행위를 포괄하는 용도로 사용해야만 한다.** 그 기능을 그 제차로만 따로 때어놓고 선언할 수는 없다. **행위는 한 객체에 포함되어야만 한다.** 때때로 이런 유형의 행위가 여러개의 서로 다른 클래스의 객체에 걸처서 동작하기도한다.
 
 예를 들어 한 계좌에서 다른 계좌로 돈을 보내는 경우를 생각해보자. 이러한 기능은 보내는 계좌와 받는 계좌 중 어느 쪽에 존재햐아할까? **이것은 양쪽 어디에두 두어도 잘못된 것이다.**
 
@@ -64,7 +64,7 @@
 
 **집합은 데이터를 변경할 때 하나의 단위로 간주되는 관련된 객체들의 집합이다.** 집합은 하나의 객체의 외부와 내부를 가르는 경계를 정해 구분한다. 집합은 하나의 root를 지닌다. root는 엔티티이고 외부에서 접근할 수 있는 창구다. root는 집합된 다른 객체들을에 대한 참조를 담고 있으며, 다른 객체들은 서로 관계를 맺고있다. 그러나 **객체의 외부에서는 root 객체를 통해서만 참조할 수 있다.** 그 경계 안에 다른 엔티티가 있다면 이러한 엔티티의 식별자는 직역적이어서 집합 내부에서만 의미가 있다.
 
-집합이 어떻게 데이터 무결성을 보장하고 불변식을 강제할 수있을까?바로 다른 객체들은 root에 대한 참조만 지니기 떄문이다. 다시 말해 다른 객체들은 집합에 속한 객체들을 변경할 수 없다는 말이다. 다른 객체들은 root를 바꾸거나, root에게 어떤 행동을 수행하라고 요청할 수 있을 뿐이다. 그리고 root에게 어떤 행동을수행하라고 요청할 수 있을 뿐이다. **그리고 root는 다른 객체들을 변경할 수 있지만 이러한 변경은 집합 안에 포함된 오퍼레이션이고, 이 오퍼레이션은 제어가 가능하다. 만약 root가 삭제된다면 집합속에 다른 모든 객체도 삭제된다.** 왜냐하면 내부 객체들 참조하는 외부의 다른 객체가 존재하지 않기 때문이다. 왜내하며ㅑㄴ 내부ㅡ 객체를 참조하는 외부의 다른 객체가 존재하지 않기 때문이다. root에 변경이 가해질 때 집합에 있는 모든 객체에 간섭적으로 영향을 주게 되며, root가 변경을 처리하는 작업을 수행하기 때문에 불변성을 강제하기가 쉽다. 
+집합이 어떻게 데이터 무결성을 보장하고 불변식을 강제할 수있을까?바로 다른 객체들은 root에 대한 참조만 지니기 때문이다. 다시 말해 다른 객체들은 집합에 속한 객체들을 변경할 수 없다는 말이다. 다른 객체들은 root를 바꾸거나, root에게 어떤 행동을 수행하라고 요청할 수 있을 뿐이다. 그리고 root에게 어떤 행동을수행하라고 요청할 수 있을 뿐이다. **그리고 root는 다른 객체들을 변경할 수 있지만 이러한 변경은 집합 안에 포함된 오퍼레이션이고, 이 오퍼레이션은 제어가 가능하다. 만약 root가 삭제된다면 집합속에 다른 모든 객체도 삭제된다.** 왜냐하면 내부 객체들 참조하는 외부의 다른 객체가 존재하지 않기 때문이다. 왜내하며ㅑㄴ 내부ㅡ 객체를 참조하는 외부의 다른 객체가 존재하지 않기 때문이다. root에 변경이 가해질 때 집합에 있는 모든 객체에 간섭적으로 영향을 주게 되며, root가 변경을 처리하는 작업을 수행하기 때문에 불변성을 강제하기가 쉽다.
 
 **만약 집합의 객체들이 데이터베이스에 저장되어 있다면 질으문을 통해서 얻을수 있는 유일한 객체는 root 뿐이다.** 다른 객체들은 관계를 따라가면서 얻어야 한다. 엔티티와 값 객체들 집합 내부에 포함시키고 각 집합 간 경계를 설정하라. 엔티티를 하나 선정하여 각 집합의 root로 삼고, 경계 내부의 객체들에는 root를통해서만 접근하도록 제어하라. 외부 객체들은 root에 대해서만 참조할 수 있어야 한다.