Clean Architecture
클린 아키텍처의 개념은 2012년에 Robert C. Martin (Uncle Bob)님이 블로그에 기재하며 세상에 나오게 되었습니다. Clean Architecture의 목표는 계층을 분리하여 관심사를 분리하는 것입니다. 사용자에게 제공되는 어플리케이션은 수많은 기능들이 있기 때문에 복잡도가 높고 유지보수의 용이함을 고려하여 구조화 해야 합니다. 클린 아키텍처는 총 4가지의 계층으로 이루어져 있습니다.
의존성 규칙은 반드시 외부에서 내부로, 저수준 정책에서 고수준 정책으로 향해야 합니다. 위 그림에서는 안쪽으로 갈수록 의존성이 낮아집니다.
각 계층의 역할에 대해 알아볼까요 ?
- Entities - 엔티티는 가장 일반적이면서 고수준의 규칙을 캡슐화하게 됩니다. 다시 말해, 엔티티는 비즈니스 규칙을 캡슐화합니다.
- Use cases - 유스케이스는 만들고자 하는 서비스를 사용하는 유저가 이 서비스를 통해 하고자 하는 것을 말해주는 "Screaming Architecture" ,그 자체로 해당 소프트웨어가 무엇인지 알 수 있도록 명확해야 합니다. 즉, 최소 요청 단위라고 할 수 있습니다.
- Interface Adapters & Presenters - 인터페이스 어댑터는 순수한 비즈니스 로직을 담당하는 역할을 합니다. Domain에 해당하는 Entity와 Usecase의 형식에서 데이터베이스에 적용할 수 있는 형식으로 변환합니다.
- Frameworks & Drivers - 프레임워크, 데이터베이스, UI, Http Client 등으로 구성된 가장 바깥쪽 계층입니다.
이와 같이 관심사를 분리하면 장점이 뭘까요?
- 프로젝트 유지 관리에 용이하다.
- 테스트 코드 작성에 용이하다.
- 새로운 기능을 빠르게 적용하고 수정할 수 있다.
Android Clean Architecture
클린 아키텍처를 안드로이드에 적용시킬 때는 위의 그림과 같이 Presentation, Data, Domain 총 3개의 계층으로 나눠지게 됩니다. 다음 계층들이 어떤 역할을 하는지 알아봅시다.
1. Presentation
UI와 관련된 부분을 담당합니다. Activity, Fragment, ViewModel 및 Presenter를 포함합니다. 프레젠테이션 계층은 가장 바깥쪽에 위치하여 Domain 계층과 의존성을 가집니다.
2. Data
Repository 구현체와 Datasource, 서버 통신과 같은 데이터를 포함합니다. 또한 mapper 클래스를 사용하여 데이터 계층의 모델을 Domain 계층의 모델로 변환해주는 역할을 하게 됩니다. Data 계층은 Domain 계층에 의존성을 가집니다.
3. Domain
어플리케이션의 비즈니스 로직에 필요한 Entity와 Usecase를 포함하고 있습니다. (+ Repository 인터페이스를 포함합니다.) Presentation과 Data 계층에 대한 의존성을 가지지 않고 독립적으로 분리되어 있습니다.
Conclusion
클린 아키텍처를 도입한 프로젝트들을 진행해보며 개념을 잘 알지 못하고 사용하고 있었던 것을 깨닫게 되었고 각 계층이 어떤 역할을 하는지 확실히 알고 사용하는 것이 중요하다는 것을 다시금 느끼게 되었습니다. 프로젝트 크기가 커질수록 큰 효과를 얻을 수 있고 멀티 모듈을 사용하여 확실하게 관심사를 분리하여 사용해준다면 앞으로 더 좋은 코드를 짤 수 있을 것 같습니다. 해당 아키텍처를 적용한 프로젝트는 다음 포스트에서 보다 자세하게 적어보겠습니다!
Top comments (0)