Clean Architecture 개요

S/W는 외부요인으로 인해 변경을 요청받게 됩니다. 외부요인이란 새로운 디바이스의 출시, 프레임워크의 변경 및 다양합니다. 작은 변경사항도 소스 코드내 미치는 영향을 줄이기 위해 클래스간 의존성을 끊어내고, 변경을 잦은 내용과 그렇지 않은 것을 구분하여 격리시켜야 합니다.

클린 아키텍처의 목적

• 시스템을 만들고 유지하는 비용을 최소화 → 유지보수성
• 외부요인으로 부터 독립적으로 작동하게 하며, 테스트 용이성과 시스템의 다른 부분을 변경하거나 교체하는데 드는 비용을 낮춤
• 새로운 기능에 대해서 추가나 변경의 용이성

경계(boundary) 만들기

• 소프트웨어 아키텍의 시작은 선을 긋고 경계를 만들어 나가는 것으로 부터 시작해야합니다.
• 경계의 한 편엔 반대편에 있는 요소를 알지 못하게 막고, 변경 사항이 발생했을 때, 핵심적인 업무(비즈니스 로직) 로직들을 오염 시키는 것을 막습니다.
• 선을 그어가면서 저수준 모듈과 고수준 모듈을 만들어 가는게 아키텍처이고, 아키텍처를 진화시키고 고도화 시킨게 클린 아키텍처 입니다.

클린 아키텍처

소프트웨어의 구조를 설계할 때 지켜야 할 원칙과 방법을 정의한 개념

공통사항

클린 아키텍처는 각자의 계층에서 사용하기 가장 편리한 타입(model)을 선언하여 사용합니다.

의존성 규칙

• 의존성은 반드시 바깥에서 안쪽으로 흘러가야 합니다.
  • Frameworks & Drivers → Interface Adapters → Application Business Rules → Enterprise Business Rules
• 내부의 원은 외부의 원에 대해서 알지 못해야 합니다.
  • ex) Entities는 Use Cases를 알면 안됩니다.
  • 외부의 원에서는 내부의 원을 의존하고 있기 때문에 내부를 알 수 있습니다.
• 외부 동심원에 의해서 내부를 변경하는 일은 없도록 해야합니다.
  • ex) UI의 변경으로 인해서 Eintites를 변경하면 안됩니다.
  • ex) SQLite에서 Room으로 마이그레이션을 진행 시 UseCase의 세부 구현이나 클래스 이름, 메서드 파라미터 등이 변경되선 안됩니다.

엔티티

• 핵심적인 내용을 캡슐화합니다. 클린 아키텍처 다이어그램에 가장 내부에 존재합니다.
  • 핵심적인 내용은 규칙, 행동, 로직 등이 있습니다.
• 가장 고수준으로 엔티티는 변경이 되지 않을만한 것들이 들어가야 합니다.
  • 엔티티에 들어가는 클래스들은 메서드들을 갖는 객체일수도, 모델, 함수의 집합일 수도 있습니다.

유즈케이스

• 애플리케이션이 갖는 기능(function) 입니다. 비즈니스 로직을 등을 단일 책임 원칙을 준수하고 캡슐화하며, 구현하는 계층입니다.
  • 위 의존성 규칙과 같이 유즈케이스의 변화가 엔티티에 영향을 줘서는 안됩니다.
    • 이는 모든 동심원에 적용합니다.
• 유즈케이스는 단일 책임 원칙(SRP)을 준수하여 하나의 기능만 수행하도록 구현하는 것이 가장 일반적입니다.
  • ex) 사용자 목록을 가져오는 기능을 캡슐화하여 getUserList 같은 클래스
    • 상세한 구현 내용이 없고(고수준), 추상적이어야 합니다.
• 단일 기능을 갖는 추상적인 interface나 class가 포함됩니다.

인터페이스 어댑터

• 계층에서 가장 편리한 방식으로 변환합니다.
• 유즈케이스(Use Cases)에서 선언된 추상화된 interface나 abstract class의 상세 구현을 해당 계층에서 진행합니다.
• 유즈케이스 계층에 선언된 내용을 인터페이스 어댑터 계층에서 상속받아 구현하게 되더라도, 결국 유즈케이스를 호출하는 파라미터 타입, 리턴 타입 등이 일반적으로 엔티티 계층에서 선언된 모델 타입입니다.
• 즉, 인터페이스 어댑터 계층은 클린 아키텍처 다이어그램에서 동심원 계층을 횡단할 때, 해당 계층이 이해하기 쉬운 타입으로 변환하는 것 입니다.
  • ex) 유즈케이스와 엔티티, DB 및 UI의 데이터 변환을 하게 됩니다.
    • DB에 있는 내용을 UI에 표현하려면 계층을 횡당하게 되는데, 횡단할 때 마다 데이터를 형변환을 합니다.

프레임워크 및 드라이버

• 안드로이드 프레임워크 및 라이브러리를 포함한 세부적인 내용 입니다.

동심원은 꼭 4개?

• 클린 아키텍처의 동심원들은 예시일 뿐입니다. 주어진 상황에 따라서 더 많거나 적은 동심원이 존재할 수 있습니다.
• 동심원의 수와 상관없이 변하지 않는 조건은 의존성 규칙입니다.