fix: Edit image path

- Edit chapter07, chapter08, chapter09, chapter10, chapter11

chapter07/zhoon/README.md

@@ -27,7 +27,7 @@
 
 ## 징후 1: 우발적 중복
 
-![0.png](/img/chapter07/zhoon/0.png)
+![0.png](/clean-architecture/img/chapter07/zhoon/0.png)
 
 - 급여 애플리케이션의 `Employee` 클래스
   - `calculatePay()`, `reportHours()`, `save()` 라는 메서드를 가진다.
@@ -64,12 +64,12 @@
 - 세 클래스는 서로의 존재를 몰라야 한다.
 - 따라서 ‘우연한 중복’을 피할 수 있다.
 
-![1.png](/img/chapter07/zhoon/1.png)
+![1.png](/clean-architecture/img/chapter07/zhoon/1.png)
 
 - 하지만 이 해결책은 개발자가 세 가지 클래스를 인스턴스화하고 추적해야 하는게 단점
 - 이러한 난관을 빠져나올 때 흔히 쓰는 기법으로 Facade 패턴이 있다.
 
-![2.png](/img/chapter07/zhoon/2.png)
+![2.png](/clean-architecture/img/chapter07/zhoon/2.png)
 
 - 어떤 개발자는 가장 중요한 업무 규칙을 데이터와 가깝게 배치하는 방식을 선호한다
   - 이 경우라면 가장 중요한 메서드는 기존의 Employee 클래스에 그대로 유지하되

chapter08/zhoon/README.md

@@ -28,7 +28,7 @@
 - SRP 를 적용하면
   - 보고서 생성이 두 개의 책임으로 분리됨
 
-![0.png](/img/chapter08/zhoon/0.png)
+![0.png](/clean-architecture/img/chapter08/zhoon/0.png)
 
 - 모든 컴포넌트 관계는 단방향으로 이뤄짐
   - `Interactor` 는 `OCP` 를 가장 잘 준수할 수 있는 곳에 위치
@@ -39,7 +39,7 @@
     - `Interactor` 이외의 컴포넌트는 모두 주변적인 문제를 처리
     - `Interactor` 는 가장 중요한 문제를 담당
 
-![1.png](/img/chapter08/zhoon/1.png)
+![1.png](/clean-architecture/img/chapter08/zhoon/1.png)
 
 - 보호의 계층구조가 ‘수준(`level`)’ 이라는 개념으로 어떻게 생성되는지 주목
 - 이게 바로 아키텍처 수준에서 `OCP` 가 동작하는 방식

chapter09/zhoon/README.md

@@ -11,7 +11,7 @@
 
 ## 상속을 사용하도록 가이드하기
 
-![0.jpg](/img/chapter09/zhoon/0.jpg)
+![0.jpg](/clean-architecture/img/chapter09/zhoon/0.jpg)
 
 - 이 설계는 `LSP` 를 준수함
   - `Billing` 애플리케이션의 행위가 `License` 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문
@@ -21,7 +21,7 @@
 
 - LSP 를 위반하는 유명한 문제
 
-![1.jpg](/img/chapter09/zhoon/1.jpg)
+![1.jpg](/clean-architecture/img/chapter09/zhoon/1.jpg)
 
 - Square 는 Rectangle 의 하위 타입으로는 적합하지 않음
 - 이런 형태의 LSP 위반을 막기 위한 유일한 방법은 (if 문 등을 이용해서) Rectangle 이 실제로는 Square 인지를 검사하는 매커니즘을 User 에 추가하는 것

chapter10/zhoon/README.md

@@ -2,15 +2,15 @@
 
 ## Introduction
 
-![0.jpg](/img/chapter10/zhoon/0.jpg)
+![0.jpg](/clean-architecture/img/chapter10/zhoon/0.jpg)
 
 - 그리고 OPS 가 정적 타입 언어로 작성된 클래스라고 해보자
 - 이 경우 User1 에서는 op2, op3 를 전혀 사용하지 않음에도 User1 의 소스코드는 이 두 메서드에 의존하게 됨
 - 이러한 의존성으로 인해 OPS 클래스에서 op2 의 소스코드가 변경되면 User1 도 다시 컴파일 후 새로 배포해야 함
   - 사실 User1 과 관련된 코드는 전혀 변경되지 않았지만!
 - 이런 문제는 아래처럼 인터페이스 단위로 오퍼레이션을 분리하여 해결할 수 있음
 
-![1.jpg](/img/chapter10/zhoon/1.jpg)
+![1.jpg](/clean-architecture/img/chapter10/zhoon/1.jpg)
 
 ## ISP와 언어
 
@@ -31,7 +31,7 @@
   - 소스 코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문
 - 하지만 더 고수준인 아키텍처 수준에서도 마찬가지 상황이 발생함
 
-![2.jpg](/img/chapter10/zhoon/2.jpg)
+![2.jpg](/clean-architecture/img/chapter10/zhoon/2.jpg)
 
 - S 시스템에서 F 프레임워크를 시스템에 도입하고자 하고, F 프레임워크 개발자는 D 데이터베이스를 반드시 사용하도록 만들었다고 가정
 - S 는 F 에 의존하고, F 는 다시 D 에 의존하게 됨

chapter11/zhoon/README.md

@@ -51,7 +51,7 @@
 - 사실상 모든 언어에서 객체를 생성하려면 해당 객체를 구체적으로 정의한 코드에 대해 소스 코드 의존성이 발생하기 때문
 - 대다수의 객체 지향 언어에서 이처럼 바람직하지 못한 의존성을 처리할 때 추상 팩토리를 사용하곤 함
 
-![0.jpg](/img/chapter11/zhoon/0.jpg)
+![0.jpg](/clean-architecture/img/chapter11/zhoon/0.jpg)
 
 - 곡선은 시스템을 두 가지 컴포넌트로 분리
   - 하나는 추상 컴포넌트