Clean Architecture

 

안녕하세요 :) Zedd입니다.

Zedd신곡 나왔는데...엄청 좋아요

갓제드ㅠ 이거들으면서 쓰는 중

 

오늘은..클린 아키텍쳐 + MVVM에 대해서 공부를 해보려고 합니다!

클린 아키텍쳐는 한번쯤은 들어보셨을 것 같아요! 저도 엄청 많이 들어봤는데.......잘 모릅니다;;

 

아무튼 이 "클린 아키텍쳐"는 로버트 C. 마틴 선생님;;이

"클린 아키텍쳐"라는 제목으로 블로그에 글을 쓰면서 알려지게 되었어요.

 

로버트 C. 마틴 이 분 소개를 잠깐 하고 가자면,

쌉고수 미국 소프트웨어 엔지니어입니다. 

 

ㅇㅣ 사람이 쓴 책

 

그 유명한...클린코드를 쓰신 분...

 

소프트웨어 개발 방법론 중 에자일 아시죠? 

이 에자일의 창시자;;;;;;; 중 한명이기도 합니다.

에자일 선언문에 가보시면 옆에 로버트 C. 마틴 적힌거 볼 수 있음..

 

SOLID(솔리드)원칙 들어보셨나요? 

이 SOLID라는 개념도 로버트 C. 마틴이 만든겁니다!

 

로버트 C. 마틴은 엉클 밥(Uncle Bob)...이라는 별명(?)으로도 불려요. 

그러니까 로버트 C. 마틴이 아니라 엉클밥..또는 밥아저씨..라는 단어가 나오면

아 로버트 C. 마틴을 말하는 거구나~ 라고 생각하시면 됩니다.

 

아무튼 오늘 공부 할 "크-린 아키텍쳐"도..마틴이 만든거 ㅇㅇ

만든거..? 좀 어감이 그런데..고안한거라고 합시다..

 

마틴이 개발 하는 동안 뭐 별에별 아키텍쳐가 다 나왔을 거 아니에요.

마틴이 그 아키텍쳐들을 보니까 일단 완전 세부적인 것들은 다 다른데

잘보면 서로 엄청 유사한거에요.

 

일단 얘네들은

 

- 같은 목표를 가짐

- 소프트웨어를 계층(layer)로 나눠서 관심사를 분리함.  

 

이렇게만 하면 어떤 소프트웨어가 만들어지냐면

---

1. Independent of Frameworks. 아키텍쳐는 소프트웨어 라이브러리의 존재에 의존하지 않음.

2. Testable. 비즈니스 로직은 UI, DB, 웹 서버 또는 기타 외부 요소 없이 테스트 할 수 있음.

3. Independent of UI. UI는 시스템을 변경하지 않고도 쉽게 변경 가능. (ex. 비즈니스 로직을 바꾸지 않고 웹 UI를 콘솔 UI로 변경가능.)

4. Independent of Database. 비즈니스 로직이 DB에 바인딩 되지 않음. 

5. Independent of any external agency. 비즈니스 로직은 외부 세계;;(outside world에 대해 전혀 알지 못함

---

마틴은 이런 다양한 아키텍쳐를 단일 아이디어로 통합하길 원했고,

그러면서 소개한 아이디어가 클린 아키텍쳐 입니다. 

 

클린 아키텍쳐의 다이어그램

 

일단 다이어그램 보자마자 아앗ㅎ~~~!!!!..개복잡해..ㅎ@@1!!!@#$#$

 

..

일단 공부해봅시다. 

 

The Dependency Rule

---

저 원은 소프트웨어의 각각의 다른 영역들을 나타내는겁니다.

 

outer circles - mechanisms

inner circles - 정책

이 아키텍쳐를 작동시키는 가장 우선적인 규칙은 Dependency Rule이에요.

 

---

Dependency Rule 

- 소스코드 종속성은 안쪽으로만 향할 수 있음.

- inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음.

- 특히, outer circles에 선언된 이름은 inner circles에서 언급해서는 안된다. (함수, 클래스 등등)

---

 

한마디로 outer circles이 inner circles에 영향 안미쳤으면 좋겠음!!!! 임

 

ㅇㅋ 이까지 이해가능

아무튼 이 Dependency Rule을 유념하고 크-린 아키텍쳐를 공부하시면 됩니다.

클린 아키텍쳐를 공부하면서 볼 예제를 소개하겠습니다.

 

간단한 영화검색 앱입니다!

영화를 검색하면 해당 단어가 들어가는 영화를 보여주고, 스크롤하면 더 불러오기까지 됩니다.

특정 영화를 누르면 해당 영화의 사진, 제목, 설명을 보여주는 화면으로 이동하게 됩니다.

검색 기록까지 남겨줍니다.

github.com/kudoleh/iOS-Clean-Architecture-MVVM

kudoleh/iOS-Clean-Architecture-MVVM

에서 다운로드 받으실 수 있습니다. 

 

자..그럼 제일 안쪽에 있는

엔티티부터 공부해봅시다.

 

 

Entities

---

엔티티는 "Enterprise wide business rules"을 캡슐화하는 친구에요.

외부 변화가 있을 때 변경될 가능성이 가장 적은.. 

일반적으로 가장 높은 수준의 규칙을 캡슐화 합니다.

자 그럼 우리의

영화 검색앱에서는 뭐가 엔티티일까요? 

"일반적으로 가장 높은 수준의 규칙"..

"Movie"라는 데이터 구조가 엔티티입니다.

간단하게 생각하시면 엔티티는 

데이터 구조 및 함수 집합..이라고 생각하시면 될 것 같아요.

영화 검색 앱에서는 뭐가 아무리 바뀌든간에 영화 검색 앱이니까 무조건 영화에 대한 정보를 보여줄거잖아요?

그러니까 이 Movie라는 데이터 구조가 가장 높은 수준의 규칙이라고 말할 수 있을 것 같아요.

 

Use cases

---

Use cases는 저 빨간색 원이에요. 

Use cases는 "시스템의 동작을 사용자의 입장에서 표현한 시나리오"에요.

이 Use cases circle은 시스템의 모든 Use cases를 캡슐화하고 구현합니다.

 

 Use cases는 엔티티와의 데이터 흐름을 조정하고,

해당 엔티티가 Use cases의 목표를 달성하도록 "지시"하는 역할을 합니다.

 

말로 하니 잘 모르겠네요. 

이 영화 검색 앱에서 Use cases는 뭘까요!?

님들 이 앱을 써야한다고 생각해보셈

그럼 이 앱 가지고 뭐할거?????;;;

 

영화를 검색하겠죠?

Use cases는 사용자에게 보여줄 출력을 위해

해당 출력을 생성하기 위한 처리 단계를 기술하는 곳이라고 보면 됩니다.

이 Use cases를 Use cases Interactor라고도 한대요.

 

Entities는 이 Use cases에 대해 전혀 알지 못합니다. 하지만 Use cases는 Entities를 알고있죠. 

하지만 이 Use cases 계층의 변경이 Entities에 영향을 미쳐서는 안됩니다.

또한 Use cases가 DB, UI 같은 외부 환경의 변경으로 인해 영향을 받지 않아야 합니다.

왜냐면 그냥 정말 단순히 Use cases이기 때문에

데이터가 어디에 저장되어있든 외부 프레임워크가 바뀌든 상관없는거에요.

하지만! 앱 전체의 작동 방식 변경(?)은 Use cases에 영향을 미칠 수 있습니다.

사용자의 시나리오가 바뀐다는 거니까요.

 

Interface Adapters

---

다음 원입니다.

다음 초록색 원은 

 

Controllers, Gateways, Presenters라고 적혀있네요.  

이들을 Interface Adapters라고 합니다. 

그림에서 볼 수 있듯이, 이 Interface adapter에 (View)Controllers, Gateways, Presenters가 속합니다. 

이 계층을 Interface Adapters라고도 하고, Presentation Layer라고도 합니다.

 

이 계층이 하는 역할을 설명해드릴게요. 이 계층에 데이터가 딱 들어오면

Entities, Use cases에 가장 편리한 format에서

DB 등과 같은 외부 프레임워크에 가장 편리한 format으로 변환되는 곳입니다.

즉, DB는 딱 이 원까지만 알아야합니다.

Use cases, Entities에 있는 코드들은 DB에 대해 아는것이 1도 없어야 합니다.

 

Frameworks and Drivers.

---

 

자, 이제 가장 바깥쪽의 원을 공부해봅시다. 

이 계층에는 일반적으로 DB, 프레임워크 같은 것들로 구성이 됩니다. 

 

그러니까 Dependency Rule의 방향을 보면, 

DB -> Adapter -> Use Cases -> Entities로 되는 것을 볼 수 있죠!

 

Only Four Circles?

---

지금은 4개의 원만 있잖아요? 꼭 4개여야하냐?

당연히 아닙니다. 원이 몇개든 Dependency Rule만 안쪽을 향하면 됩니다. 

안쪽으로 갈수록 추상화 수준이 증가하면 됩니다.

 

Crossing boundaries.

---

다이어그램의 우하단을 보면, 원 경계를 교차하는 방법의 예가 있습니다. 

분홍색 선을 볼까요? Controller에서 시작해서 Use Case를 거쳐 Presenter에서 실행되는 군요. 

"Use case를 거쳐 Prsenter에서 실행되는 군요"

그럼 결국 Use case가 Presenter를 호출 할 수도 있습니다. 근데 우리가 처음에 뭐랬죠????

 

---

Dependency Rule 

- 소스코드 종속성은 안쪽으로만 향할 수 있음.

- inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음.

- 특히, outer circles에 선언된 이름은 inner circles에서 언급해서는 안된다. (함수, 클래스 등등)

---

 

Use case가 Presenter를 호출한다는건

Use case가 Presenter에 대해서 안다는 소리가 되죠.

근데 그러면 안되는 부분임

 

그래서 

Output Port라는 "인터페이스"를 둡니다.

그래서 Use case는 이 Output port에 있는 인터페이스를 호출합니다.

그리고 Presenter는 이 Output port 인터페이스를 구현하죠.

직접 Presenter의 구현체에 접근을 안하고 인터페이스를 통해 접근한다는 것이 가장 중요합니다. 

 

 

자 대충 크-린 아키텍쳐가 뭐 이런거다? 이런 느낌이다만 아시면 될 것 같아요.

저는 우리가 잠깐 본 영화 검색 앱...

github.com/kudoleh/iOS-Clean-Architecture-MVVM

kudoleh/iOS-Clean-Architecture-MVVM

이걸 클린 아키텍쳐+MVVM을 사용해서 만들었다고 해요. 

출처 https://github.com/kudoleh/iOS-Clean-Architecture-MVVM

일단 폴더 많은거 개짱나긴 하는데

DI쪽이 신기해서 살펴볼 예정입니다. 

 

글에 틀린 부분이 있다면 꼭!!! 말씀해주세요.

엄청 찾아보면서 하긴 했는데..그냥 혼자 공부하면서 정리한거라..틀린 부분이 있을 수 있습니다.

원문은 밥아저씨가 쓴 blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

요 글이니...자세한 내용은 이 글을 참고해주세요.

 

참고

blog.coderifleman.com/2017/12/18/the-clean-architecture/

github.com/kudoleh/iOS-Clean-Architecture-MVVM

blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

m.blog.naver.com/PostView.nhn?blogId=suresofttech&logNo=220845781030&proxyReferer=https:%2F%2Fwww.google.com%2F

tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3