diff --git a/The Clean Architecture/Will/What is Clean Architecture?.md b/The Clean Architecture/Will/What is Clean Architecture?.md new file mode 100644 index 0000000..b1a3547 --- /dev/null +++ b/The Clean Architecture/Will/What is Clean Architecture?.md @@ -0,0 +1,75 @@ +## Q) 아키텍처를 사용해서 보다 가독성있고 가용성있게 코드를 작성해야할 필요성을 느끼는 건 맞지만 왜 Clean Architecture여야만 하는가? + +### a. 좋은 아키텍처는 다음을 수행합니다. + +1. `가독성있고`, `유지 보수 및 배포하기 쉬운 시스템` 만들기 +2. `시스템 정책을 분리` +3. 시스템을 `테스트 가능`하게 만들기 +4. `코드 재사용성` 장려 + +### b. 클린 아키텍처란? + +클린 아키텍처는 개발자라면 클린 코드를 저술한 로버트 마틴(Robert C. Martin)이 제안한 `시스템 아키텍처`로, 기존의 `계층형 아키텍처`가 가지던 의존성에서 벗어나도록 하는 설계를 제공합니다. + +### c. 그래서 왜 클린 아키텍처가 필요한가? + +nhncloud 블로그 발췌) + +여러분이 A 배달 앱의 개발자이며, 어느 날 A 배달 앱이 B 배달 앱과 통합된다고 가정하겠습니다. 이때 여러분은 다음과 같은 요구를 받게 됩니다. + +**“A 배달 앱 시스템이 잘 되어 있으니 A 앱의 핵심 기능은 유지하고, `UI`와 `DB` 쪽만 바꿔 주세요.”** + +또는 다음과 같은 요구를 받을 수도 있습니다. + +**“A 배달 앱이 너무 잘되니 서비스를 `웹으로 확장`해 봅시다.”** + +비즈니스의 로직은 비슷한데, 변경해야 하는 부분도 많고, 아예 새로 만들 수도 없는 이러한 상황이라면, 여러분은 어떻게 하실 건가요? + +만약 클린 아키텍처를 도입했다면, 단순하게 `**인터페이스 어댑터 영역**`과 **`프레임워크`**와 **`드라이브 영역`**만 수정하면 됩니다. 왜냐하면 ‘고객과 업체 사이에서 배달 서비스를 중계한다’는 비즈니스 로직은 변하지 않았기 때문입니다. 이와 같이 클린 아키텍처는 비즈니스 로직은 바꾸지 않으면서, 언제든 DB와 프레임워크에 구애 받지 않고 교체할 수 있는 아키텍처인 셈입니다. + +⇒ `시스템 정책을 분리` 및 `유지 보수` 용이 + +
+ +`Clean Architecture` 시스템 아키텍처 도식화 + + + +### Domain Layer + +가장 깊은 계층으로 다른 계층을 의존하지 않음. 다른 계층의 어떤 것(프로퍼티, 함수)도 포함하지 말아야 함 + +`Entities(Business Models)`, `Use Cases`, and `Repository Interfaces`을 포함하는 계층 + +- **Use Case**: `비즈니스 로직`이 들어 있는 영역 +- **Entity**: `화면에 표시할 데이터` + +### Presentation Layer + +하나 이상의 `Use Cases`를 실행하는 `ViewModel`은 `View`를 조정. `Presentation Layer`는 오직 `Domain Layer`만 의존. + +- **View**: `화면에 데이터를 표시` +- **Presenter**: `ViewModel`과 같은 역할을 하고 사용자 `인터렉션을 어떻게 처리할지(핸들링)`하는 영역 + +### Data Layer + +저장소의 구현부들과 하나 이상의 `Data Sources`를 포함하는 계층. + +서로 다른 `Data Sources`를 조정(Encoding, Decoding). + +- **Repository**: `Use Case`가 필요로 하는 데이터의 `(post, get, put, delete)`와 `CRUD` 등의 기능을 제공하는 영역으로, 데이터 소스를 인터페이스로 참조하여, `네트워크 통신`과 `로컬 DB`을 자유롭게 할 수 있습니다. +- **Data Source**: `실제 데이터의 입출력` + +### QA) 상위 하위 모듈로 나누는 기준 + +상위: 변하기 어려운 것 + +하위: 변하기 쉬운 것 + +※ 참고 출처 + +[codemagic](https://blog.codemagic.io/clean-architecture-explored/) + +[nhncloud](https://meetup.nhncloud.com/posts/345) + +[kudoleh](https://github.com/kudoleh/iOS-Clean-Architecture-MVVM) \ No newline at end of file