클린 아키텍처: Typescript 및 React

깨끗한 아키텍처 를 사용 하면 결합도가 매우 낮고 데이터베이스 및 프레임워크와 같은 기술 구현 세부 사항과 독립적인 애플리케이션을 설계할 수 있습니다. 이렇게 하면 응용 프로그램을 유지 관리하기 쉽고 유연하게 변경할 수 있습니다. 또한 본질적으로 테스트 가능해집니다. 여기에서는 클린 아키텍처 프로젝트를 구성하는 방법을 보여 드리겠습니다. 이번에는 Typescript를 사용하여 React todo 애플리케이션을 빌드할 것입니다.

프로젝트의 폴더/그룹 구조는 다음과 같은 형식을 취합니다.

├── Core 
├── Data 
├── Domain 
└── Presentation

이 계층은 프로젝트 /응용 프로그램이 수행하는 작업을 설명합니다. 많은 응용 프로그램은 폴더 구조만 보고 응용 프로그램이 수행하는 작업을 이해할 수 없는 방식으로 구축되고 구조화됩니다. 집의 건물 비유를 사용하면 건물의 평면도와 입면도를 보고 건물의 모양과 기능을 빠르게 식별할 수 있습니다.

같은 방식으로 프로젝트의 도메인 계층은 애플리케이션이 수행하는 작업을 지정하고 설명해야 합니다 . 이 폴더에서 모델, 리포지토리 인터페이스 및 사용 사례를 사용합니다.

├── Core
├── Data
├── Presentation
└── Domain
    ├── Model
    │   ├── Todo.ts
    │   └── User.ts
    ├── Repository
    │   ├── TodoRepository.ts
    │   └── UserRepository.ts
    └── UseCase
        ├── Todo
        │   ├── GetTodos.ts
        │   ├── GetTodo.ts
        │   ├── DeleteTodo.ts
        │   ├── UpdateTodo.ts
        │   └── CreateTodo.ts
        └── User
            ├── GetUsers.ts
            ├── GetUser.ts
            ├── DeleteUser.ts
            ├── UpdateUser.ts
            └── CreateUser.ts

1. Repository : 모든 저장소 인터페이스의 컨테이너. 리포지토리는 모든 모델별 작업을 보관하는 중앙 위치입니다. 이 경우 Todo 저장소 인터페이스는 저장소 방법을 설명합니다. 실제 리포지토리 구현은 데이터 계층에 보관됩니다.
2. UseCases : 애플리케이션의 모든 기능을 나열하는 컨테이너입니다. 예: Todo 가져오기, Todo 삭제, Todo 생성, Todo 업데이트

├── Core
├── Data
├── Domain
└── Presentation
    └── Todo
        └── TodoList
            ├── TodoListViewModel.tsx
            └── TodoListView.tsx

├── Core
├── Domain
├── Presentation
└── Data
    ├── Repository
    │   ├── TodoRepositoryImpl.ts
    └── DataSource
        ├── TodoDataSource.ts
        ├── API
        │   ├── TodoAPIDataSourceImpl.ts
        │   └── Entity
        │       ├── TodoAPIEntity.ts
        │       └── UserAPIEntity.ts
        └── DB
            ├── TodoDBDataSourceImpl.ts
            └── Entity
                ├── TodoDBEntity.ts
                └── UserDBEntity.ts

1. DataSource : 모든 데이터 소스 인터페이스 및 엔터티. 엔터티는 레코드로 데이터베이스에 저장된 도메인 개체의 단일 인스턴스를 나타냅니다. 여기에는 DB 테이블 또는 API 끝점에서 열로 나타내는 몇 가지 특성이 있습니다. 외부 데이터 소스에서 데이터가 모델링되는 방식을 제어할 수 없으므로 이러한 엔터티는 구현에서 엔터티에서 도메인 모델로 매핑되어야 합니다.

이러한 항목을 목록 보기에 표시할 것이므로 Identifiable을 준수해야 합니다.

다음으로 todo 엔터티를 수행해 보겠습니다.

이제 TodoDatasource에 대한 인터페이스를 작성해 보겠습니다.

이 인터페이스의 구현을 작성하기에 충분하며 이를 TodoAPIImpl이라고 합니다.

참고 : 이 데이터 소스의 getTodos 함수는 Todo 목록을 반환합니다. 따라서 TodoEntity -> Todo를 매핑해야 합니다. TodoRepositoryImpl을 작성하기 전에 도메인 계층에 해당 인터페이스를 작성하겠습니다.

이제 todo 저장소가 있으므로 GetTodos 사용 사례를 코딩할 수 있습니다.

그런 다음 프레젠테이션의 뷰 모델과 뷰를 작성할 수 있습니다.

요약하면 흐름은 다음과 같습니다.

사용 사례는 리포지토리를 참조해야 합니까? 유스 케이스 또는 뷰 모델에서 직접 데이터 소스를 호출하지 않는 이유는 무엇입니까?

소규모 프로젝트의 경우 가능할 수 있지만 보다 확장 가능한 솔루션의 경우 다음을 고려해야 할 수 있습니다.

뷰 모델은 일부 비즈니스 로직을 호출하고 뷰에 대한 결과를 준비하는 데만 관여해야 합니다. 이 경우 뷰 모델은 사용 사례만 호출해야 합니다.

사용 사례는 비즈니스 로직을 보유해야 합니다. 이 경우 todos를 검색해야 하므로(어디에서 검색해야 하는지는 신경 쓰지 않습니다) todo 저장소 "getTodos" 메서드를 호출해야 합니다.

리포지토리는 사용 사례 요청을 충족하기 위해 어떤 데이터 소스와 서비스를 사용해야 하는지에 관심을 가져야 합니다. 프로젝트가 더 복잡하지만 여전히 확장 가능한 구조로 성장할 수 있으므로 이를 더 명확하게 볼 수 있습니다.

할 일이 API에서 검색된 후 로깅 DB에 무언가를 기록하려고 합니다.

GitHub 저장소:https://github.com/nanosoftonline/clean-typescript-react

원래 https://nanosoft.co.za 에 게시되었습니다 .