Clean Architecture 클린아키텍처에 대하여 [1부]

내가 사이드잡을 시작하면서 Flutter의 Clean Architecture를 지키며 코딩을 하기위해 공부를 한 것을 정리해보도록 하겠다.

 

가급적이면 처음부터 쭉 읽어도 모든 내용들이 이해되도록 작성해보도록 하겠다. 최대한 교차검증으로 오류도 최소화해서 작성해보도록 하겠다.

 

 

---

1. Clean Architecture란

우선 Clean architecture란 무엇일까?

Uncle bob, Robert C. Martin이란 사람의 블로그에서 처음 등장한 것으로, 프로젝트 전반에 관련된 구조이다. 우선 그 내용은 아래 링크를 참고하길 바란다. (주의 : MVVM, MVC같은 것들은 프로젝트 전반이 아니라 UI와 비즈니스로직에 관련된 내용이다.)

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

Clean Coder Blog

1.1 Clean Architecture의 목표

clean architecture의 목표는 다음 5가지와 같다.

 

1. 프레임워크에 독립적
2. 테스트에 유용하다.
3. UI에 독립적이다.
4. 데이터베이스에 독립적이다.
5. 외부에 독립적이다.

하나하나 살펴보도록 하자.

 

우선, 프레임워크에 독립적이라는 것은, 이 클린아키텍처는 프레임워크에 종속적인것이 아니라 어느 프레임워크에도 적용이 가능하다는 뜻이다.

예를들어, Flutter라는 프레임워크에만 적용할 수 있는것이 아니라, Jetpack compose에도 적용할 수 있다는 뜻이다.

 

둘째로 테스트에 유용하다. 라는 것은 Test case를 작성해서 테스트를 하더라도 외부에 영향을 받지 않아도 테스트가 원활하게 된다는 뜻이다. 즉, 테스트할때 테스트 하는 대상 외에는 영향받는 것을 최소화한다는 것으로 종속성을 최소화 한다는 것이다. 이 종속성을 최소화한다는것이 Clean architecture의 핵심이다.

 

셋째로 UI에 독립적이라는 것은, UI의 변경이 이루어지더라도 비즈니스가 변경되지 않아도 된다는 뜻이다. 즉 UI의 코드가 변경이 되거나 더 나아가 UI가 앱에서 웹으로 변경이 되더라도 비즈니스 모델인 api연동 등 그러한 부분은 교체하지 않아도 된다는 뜻이다. 이것도 위에서 이어지는 내용,  종속성을 최소화한다는 내용이다.

 

넷째, 데이터베이스에 독립적이란 것이다. 데이터베이스가 MongoDB쓰건 NoSql기반을 쓰건 영향을 주지 않는다는 내용이다. 세부내용은 세번째의 내용과 이어지는 내용이므로, 추가로 서술하지는 않겠다.

 

마지막으로 외부기관에 독립적이라는 것은 내부는 외부를 알지못한다는 뜻으로, 추후에 다시 설명하도록 하겠다.

 

결론은, 이 Clean architecture은 시스템을 유지보수 가능하고 확장 가능하고 유연하게 만드는것이라고 할 수 있다. 

 

1.2 Clean Architecture 이미지 설명

이 원은 Clean architecture의 구성을 나타내는 이미지이다. 그러니까 이렇게 구현되는것을 권장하고 있는 것이다. 원의 외부는 내부를 의존하게 되며, 원의 내부는 외부를 전혀 알 수 없는 구조로 작성이 되어야 한다.

 

그러니까, Entity는 Usecase가 있는지 없는지 몰라야하고,(종속되지 않아야 한다.) Usecase는 Entity의 변화에 종속이 되어있어서 Entity의 변화에 맞게 변경이 된다는 뜻이다.

 

반대로 말을하자면,

바깥원에서 생성된 데이터형식은 안쪽원에 의해서 사용되어선 안되며, 바깥원은 안쪽의 원에 영향을 미치지 않아야 한다. 라는 뜻이다.

 

이제 하나하나 살펴보도록 하자.

 

이 부분은 이해가 잘 가지 않더라도, '아, 이런게 있구나.' 정도만 이해해도 좋다. 다음 2부에서 더 자세히 다루게 될 예정이므로 읽기만 하고 넘어가자.

 

Entity

• 엔터티는 핵심 비즈니스 규칙을 캡슐화한 것
• 일반적이고 고수준의 규칙을 캡슐화한다.
• 외부 변경에 영향을 가장 받지 않는 것.
• 특정 응용 프로그램의 운영변경이 이 계층에 영향을 미치지 않아야 한다.

이 Entity는 소프트웨어의 중심이 되는 비즈니스 룰(Business Rules)이므로 가장 변화가 적어야하는 것이다. 따라서 가장 내부에 존재하고 변경이 되면 모든 구조의 전반에 영향을 주게 된다.

 

Usecase

• 응용프로그램별 비즈니스 규칙이 포함되어 있다.
• 데이터 흐름을 조정한다.
• Entity에게 목표를 달성하기 위해 전반의 비즈니스 규칙을 사용하도록 한다.
• Entity에게 영향을 미치지 않으며, 응용프로그램의 영향을 받지 않는다. 단 Entity에게 영향을 받으며, 응용프로그램에게 영향을 끼친다.

Interface Adapters

• usecase 및 Entity에게 변환하기 쉬운 형태로 데이터를 변환하는 일련의 어댑터이다.
• 이 계층에는 GUI의 MVC 등 아키텍처 전체를 포함한다. (MVC MVVM 등 GUI 아키텍처를 일컫는다.)
• Presenter view 및 Controller는 이곳에 속한다.
• 이 부분은 가장 외부(Device, DB 등)에 대해 알지 못해야 한다. 예를들어 어떤 DB가 사용되었는지, 어떤 디바이스인지 몰라야 한다.

 

Frameworks and Drivers

• 가장 바깥층 계층으로, 데이터베이스, 웹 디바이스 프레임워크로 구성된다.
• 이 계층은 내부로 향하는 통신을 위한 접착코드 이외에는 추가적으로 구성하지 않는게 일반적
• 세부사항들을 포함하여 가능한 미치는 영향을 최소화하도록 한다.

 

이정도로 읽으면 된다. 물론 굉장히 뜬구름 같다고 이해가되겠지만, 쭉 읽어보고 다음포스팅을 읽으면 왜 이렇게 작성하게 되었는지 이해가 될 것이다.