Clean architecture #

Find similar titles

총 3회 업데이트 됨.

Edit

최초 작성자
mpark@insilicogen.com 2023-05-22 03:28:57
최근 업데이트
jhkim 2023-05-25 01:52:43

Structured data

Category: Programming

Clean Architecture

Clean Architecture #

목차 #

서론
개요
핵심 원칙
구성 요소
계층 구조
의존성 규칙
Flutter Framework Project 적용
결론
참고 자료

서론 #

Clean Architecture(클린 아키텍처)는 소프트웨어 시스템의 설계 원칙과 구조를 통해 유지보수할 수 있고 확장할 수 있는 소프트웨어를 만들기 위한 방법론입니다. 이 문서에서는 Clean Architecture에 대한 개요, 핵심 원칙, 구성 요소, 계층 구조, 의존성 규칙 등에 대해 다루겠습니다.

개요 #

Clean Architecture는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 아키텍처 디자인 패턴입니다. 이 패턴은 시스템을 여러 계층으로 나누고, 계층 간의 의존성을 최소화하여 시스템을 유연하고 견고하게 만들어줍니다. 또한, 테스트 용이성, 유지보수성, 재사용성 등을 높이는 목적이 있습니다.

핵심 원칙 #

Clean Architecture의 핵심 원칙은 다음과 같습니다.

독립성: 각 계층은 독립적으로 존재하며, 내부 변경이 외부 계층에 영향을 미치지 않아야 합니다.
의존성 역전: 상위 수준 모듈은 하위 수준 모듈에 의존하면 안 되며, 추상화된 인터페이스에 의존해야 합니다.
경계의 명확성: 각 계층은 명확한 경계를 가져야 하고, 인터페이스를 통해 상호작용합니다.

구성 요소 #

Clean Architecture는 다음과 같은 구성 요소로 이루어져 있습니다.

엔티티(Entity): 핵심 비즈니스 규칙을 담고 있는 도메인 객체입니다.
유스케이스(Use Cases): 비즈니스 규칙을 구현하는 유스케이스 또는 인터랙터입니다.
인터페이스 어댑터(Interface Adapters): 외부 시스템과의 상호작용을 담당하는 인터페이스 어댑터입니다.
프레젠터(Presenters): 사용자 인터페이스와 데이터 표현을 담당하는 프레젠터입니다.
데이터베이스(Database): 데이터의 영구 저장을 담당하는 데이터베이스입니다.

계층 구조 #

Clean Architecture는 다음과 같은 계층 구조로 되어 있습니다.

프레젠테이션(Presentation) 계층: 사용자 인터페이스를 담당하는 계층으로, UI 및 프레젠터가 위치합니다.
애플리케이션(Application) 계층: 비즈니스 로직을 담당하는 계층으로, 유스케이스와 인터페이스 어댑터가 위치합니다.
도메인(Domain) 계층: 핵심 비즈니스 규칙을 담당하는 계층으로, 엔티티와 유스케이스가 위치합니다.
인프라스트럭처(Infrastructure) 계층: 외부 시스템과의 상호작용을 담당하는 계층으로, 인터페이스 어댑터와 데이터베이스가 위치합니다.

의존성 규칙 #

Clean Architecture는 다음과 같은 의존성 규칙을 가지고 있습니다.

외부 계층은 내부 계층에 의존하지 않습니다. 즉, 프레젠테이션 계층은 애플리케이션 및 도메인 계층에 의존하지만, 그 반대는 성립하지 않습니다. 추상화된 인터페이스에 의존해야 합니다. 구체적인 구현에 의존하지 않고, 인터페이스를 통해 의존성을 주입받아야 합니다.

Flutter Framework Project(아이푸드) 적용 #

Clean Architecture를 저희 플러터 프로젝트(아이푸드)에 적용한 모습입니다. 이러한 설계를 통해, 저차원의 모듈(화면에 보이는 영역)은 고차원의 모듈(API)에 의존하고 이 사이에 Repository를 생성하여, 화면에 추가적인 기능 구현이 필요한 경우에 고차원의 모듈은 저차원의 모듈에 의존하지 않는 구조를 가질 수 있습니다. 즉, 고차원의 모듈은 저차원의 모듈에 대해 아무것도 몰라도 되며, 계층 분리를 통해 프로젝트 전체의 안정성이 올라가게 됩니다.

구체적인 예를 한 번 들어보겠습니다.

 getSearch() async {
    showLoading();
    SearchRequestModel requestModel = SearchRequestModel(
        page: 1, pageSize: 10, keyword: '두부', category: '식품');

    SearchResponseModel searchResponseModel =
        await menuService.menuRepository.getTestSearchIFOOD(requestModel);

    menuService.refreshFoodList(searchResponseModel.food);
    dismissLoading();
}

위 코드는 아이푸드 앱의 음식 검색 결과를 반환하는 코드입니다.

Presentation Layer의 View에서 getSearch메서드를 호출하면 음식 검색 결과 모델을 반환합니다. 만약 page, pageSize, keyword, category 외에 새로운 변수 test가 추가된다면 어떻게 될까요?

API를 직접 호출하는 고차원 모듈을 저차원 모듈에서 바뀐 내용 때문에 아래처럼 일일이 수정해줘야 할까요?

Map response = await apiResponse.call(
  method: ApiMethod.get,
  url:
      '$url/search?page=$page&page_size=$pageSize&keyword=$keyword&category=$category&test=$test',
  headers: apiResponse.getToken(),
);
if (response['status'] == true) {
  return response

구체적인 변동 사항은 Data Layer와 Presentation Layer의 중간에 있는 Repository를 통해 추상화 및 구현을 완료하고, 고차원 모듈에서는 오롯이 API Call만 담당할 수 있도록 구현하는 것 이것이 Clean Architecture의 핵심입니다. Repository 구현이 잘 되어있다면 고차원 모듈에서는 아래 소스 코드처럼 변화가 없을 것입니다.

@GET('search')
  Future<BaseResponse> getSearch(
      @Queries() Map<String, dynamic> queries);

Repository를 어떻게 구현하고, 어떻게 고차원 모듈과 저차원 모듈에서 의존성을 가져갈지는 독자 여러분께서 고민해보시기를 바랍니다.

결론 #

Clean Architecture는 소프트웨어 시스템을 유연하고 확장할 수 있게 만들기 위한 아키텍처 설계 원칙과 방법론입니다. 이를 통해 코드의 의존성을 최소화하고 각 계층을 독립적으로 유지함으로써 유지보수성과 테스트 용이성을 향상할 수 있습니다. 단점으로는 러닝 커브가 가파르고, 프로젝트에 직접 적용하는 데 많은 자원이 소요됩니다.

참고 자료 #

Robert C. Martin. "Clean Architecture: A Craftsman's Guide to Software Structure and Design" (책)
The Clean Architecture(블로그 글)