Clean Architecture

클린 아키텍처란?

로버트 C 마틴이 제시한 개념
소프트웨어 시스템 아키텍처 디자인 패턴 중 하나
소프트웨어 시스템을 설계하고 구성하는 방법
소프트웨어 시스템을 깔끔하게 유지하고 확장 가능하며 유지보수성을 높힘

아키텍처 특징

프레임워크 독립성
테스트 용이성
UI 독립성
데이터베이스 독립성
모든 외부 에이전시에 대한 독립성

가장 중요한 규칙 (의존성)

안쪽에 있을수록 고수준의 정책을 의미함
- 고수준의 정책은 바깥쪽을 의존하지 않게
의존성은 반드시 안쪽으로 향함

주요 구성 요소

엔티티

비즈니스 규칙을 담고 있는 엔티티, 가장 안쪽에 위치하며 가장 안정적인 부분
핵심 업무 규칙
외부의 변경으로부터 영향을 받지 않는 영역

유스케이스

비즈니스 규칙을 적용하고 시스템의 행위를 제어하는 부분
어플리케이션에 특화된 업무 규칙을 포함

인터페이스 어댑터

데이터를 외부와 주고받을 때 사용하는 부분
컨트롤러, 프레젠터, 게이트웨이

프레임워크와 드라이버

외부 도구, 프레임워크, 라이브러리 등과의 연결을 담당
프레임워크, 데이터베이스, 웹 서버 등

장점

1. 유지보수성 향상

각 구성 요소가 독립적으로 존재, 각각의 책임이 분명하게 정의
코드를 변경하거나 유지보수하는데 용이
변경이 필요한 부분을 신속하게 식별하고 수정

2. 확장성 및 변동성 제어

안쪽의 원은 안정적이고 변동성이 낮은 엔티티
- 시스템의 핵심 비즈니스 규칙은 안정적으로 유지
바깥쪽의 원은 변동성이 큰 부분
- 외부 요인에 대한 대응이 유연

3. 테스트 용이성

각 구성 요소는 독립적으로 테스트 가능
의존성이 명확하게 정의되어 있어 모킹등을 통한 테스트가 용이

4. 프레임워크와 도구의 유연한 교체

외부 프레임워크, 라이브러리, 디비 등과의 의존성이 인터페이스 어댑터를 통한 추상화
필요에 따라 이들을 교체하거나 업그레이드하는데 용이

5. 개발자와 비즈니스 로직의 분리

핵심 비즈니스 로직이 안쪽의 원에 위치, 엔티티
프레임워크나 인터페이스와 독립적으로 작성
개발자가 핵심 비즈니스 로직에 집중할 수 있음

6. 플랫폼 독립성

안쪽의 원에는 플래폼에 종속적인 부분이 없음 -> 엔티티
바깥쪽의 원에서 의존성, 종속성을 처리
플랫폼 간의 이식성이 향상

7. 비즈니스 규칙의 명시적 표현

비즈니스 규칙이 명시적으로 드러나도록 하는 구조를 제공
비즈니스 요구사항을 반영하도록 하며, 코드를 이해하고 관리하는데 돕는다.

8. 도메인 주도 설계(Domain-Driven Design)와의 조합

도메인 주도 설계 원칙과 잘 조화
비즈니스 규칙을 중심으로 시스템을 구성하고 확장 가능

설계

Clean Architecture에 따르는 구조화

Domain Layer

애플리케이션이 수행하는 작업을 설명
플랫폼/프레임워크와 독립적으로 구성
Model -> 문제와 관련된 실제 세계의 Object
Repository -> Model 에 접근 가능한 인터페이스 제공
UseCase -> 애플리케이션의 비즈니스 로직 포함

Model Layer 설계

데이터 모델 추출
비즈니스 규칙에 초점을 맞춘 필요한 데이터를 정의 (프레임워크, 플랫폼에 구애받지 않음)
Typescript를 이용해서 정의

export type Position = { x: number, y: number, z: number }
export type CameraType = 'perspective' | 'orthographic'

UseCase Layer 설계

"A가 발생하면 B를 수행한다." 로 정의
React에서의 UseCase
- React Application에 의해 호출되는 렌더링 함수
- 사용자 입력을 위한 이벤트 핸들러
- 자발적으로 발생되는 effect
대부분 컴포넌트 내부에서 이런 UseCase들이 스파게티처럼 뒤섞여 정의되게 된다.
- 적절한 Layer로 풀어서 정리 필요
- 변수간 의존성을 분석해서 문제를 풀어야 한다.
- 다른 변수로부터 추론할 수 없는 주요 데이터 소스를 찾고 데이터 레이어에서 관리하게 만듦

UseCase 정의 예시

import { Repository } from './repository'

export async function clickOnBoard(indexOnBoard: number, repository: Repository) {
  const { board, stepNumber } = await repository.getCurrentStep();
  const newBoard = board.slice();
  if (calculateWinnerOnBoard(newBoard) || newBoard[indexOnBoard]) return;
  
  newBoard[indexOnBoard] = isNextTurnX(stepNumber) ? "X" : "O";
  await repository.deleteStepsAfterCurrentStepNumber();
  await repostiory.addStep(newBoard);
  await repository.setCurrentStepNumber(stepNumber + 1);
}

export async function jumbToStep(stepNumber: number, repository: Repository): Promise<void> {
  return repository.setCurrentStepNumber(stepNumber);
}

Repository Layer 설계

UseCase와 Repository 사이의 boundary 설계는 주관적
Repository Layer는 모델 관련 동작들 가운데에 정의
Repository Layer 동작 원칙
- Operation 최소화 (사용하는 인터페이스들만 public하게 노출)
  - 예로 모든 getter/setter를 노출하면 일관되지 않은 데이터를 쉽게 생성 가능해진다.
- 동작은 중립적, UseCase Layer에서 정의한 비즈니스 로직과 독립적
- 각 Repository 동작은 소스간의 일관성 유지 필요
  - 한 번에 하나의 Repository 동작
  - 한 번에 여러개의 Data Source를 변경하는 경우에만 atomic operation으로 여러 data source 접근

Repository interface 설계 예시

export type Step = {
  board: Board;
  stepNumber: number;
  numOfAllSteps: number;
}

export interface Repository {
  getCurrentStep(): Promise<Step>;
  setCurrentStepNumber(): Promise<void>;
  deleteStepsAfterCurrentStepNumber(): Promise<void>;
  addStep(board: Board): Promise<void>
}

Presentation Layer

애플리케이션이 실제 세계와 상호작용하는 방식을 설명
즉, 사용자에게 화면으로 보여지는 레이어
리엑트 컴포넌트에서 사용자에게 어떤 UI를 어떻게 렌더링할지에 대해 초점을 둔다.

Presentation Layer 설계

MVC 형태를 구성하는것이 중요 (Moel, View, Controller)

Model과 Controller를 하나의 객체로 병합
Presentation Layer와 UseCase Layer 사이의 브릿지로 사용
컴포넌트 렌더 부분 (View), 커스텀 훅으로 (Model - Controller) 참조함으로써 View와 Model-Controller 분리
View에서는 커스텀훅(Model-Controller)를 통해서 상위 레이어에 있는 동작들(데이터소스)에 접근하거나 UseCase를 적용 등의 처리를 적용

Presentation Layer 설계 예시

// model-controller (커스텀 훅)
import { Repository, Step } from './repository';
import { clickOnBoard, jumpToStep } from './useCase';

export const useTicTacTocModelController = (repository: Repository) => {
  const [currentStep, setCurrentStep] = useState<Step | null>(null)
  
  useEffect(() => {
    async function init() {
      const initialStep = await repositroy.getCurrentStep();
      setCurrentStep(initialStep);
    }
    init();
  }, [repository])
  
  const handleClickOnBoard = async (indexOnBoard: number) => {
    await clickOnBoard(indexOnBoard, repository);
    const nextStep = await repository.getCurrentStep();
    setCurrentStep(nextStep);
  }
  
  const handleJumpToStep = async (stepNumber: number) => {
    await jumpToStep(stepNumber, reposit ory);
    const nextStep = await repository.getCurrentStep();
    setCurrentStep(nextStep);
  }
  
  return {
    currentStep,
    handleClickOnBoard,
    handleJumpToStep
  }
}

 // View 
 import { Repository } from './repository';
 import { useTicTacTocModelController } from './tictactocModelController';
 
 type TicTacTocViewProps = {
   repository: Repository
 }
 
 export function TicTacTocView({repository}: TicTacTocViewProps) {
   const { currentStep, handleClickOnBoard, handleJumbToStep } = useTicTacTocModelController(repository);
   
   if (!currentStep) return null;
   
   // Util functions
   const winner = calculateWinnerOnBoard(currentStep.stepNumber);
   const xIsNext = isNextTurnX(currentStep.stepNumber);
   
   return (
   ...jsx
    )
 }

Data Layer

애플리케이션이 데이터를 관리하는 방법

Data Layer 설계

Data Layer는 두개의 Sub Layer 존재
Data:Repository Layer
- Domain의 Repository Layer에 정의된 동작 구현
Data:DataSource Layer
- 실제 데이터 스토리지 구현

Data Layer 설계 예시

 // RepositoryImpl
 import { DataSource} from './dataSource';
 import { Board } from './model';
 import { Repository, Step } from './repository';
 
 export class RepositoryImpl implements Repository {
   dataSource: DataSource;
   
   cnstructor(dataSource: DataSource) {
     this.dataSource = dataSource;
   }
   
   async getCurrentStep(): Promise<Step> {
     const { history, stepNumber } = await Promise.all([
       this.dataSource.getHistory();
       this.dataSource.getStepNumber();
     ])
     const board = history[stepNumber].board;
     const numOfAllSteps = history.length;
     
     return { board, stepNumber, numOfAllSteps };
   }
   
   async setCurrentStepNumber(stepNumber: number): Promise<void> {
     const history = await this.dataSource.getHistory();
     if (stepNumber < history.length) {
       await this.dataSource.setStepNumber(stepNumber);
     } else {
       throw Error(
         `Step number ${stepNumber} should be smaller than the history size ${history.length}`
       )
     }
   }
   
   async deleteStepAfterCurrentStepNumber(): Promise<void> {
     const [history, stepNumber] = await Promise.all([
       this.dataSource.getHistory(),
       this.dataSource.getStepNumber(),
     ]);
     const trimmedHistory = history.slice(0, stepNumber + 1);
     await this.dataSource.setHistory(trimmedHistory);
   }
   
   async addStep(board:Board): Promise<void> {
     const history = await this.dataSource.getHistory();
     history.push({ board });
     await this.dataSource.setHistory(history);
   }
 }

 // DataSource Layer Inteface
 import { History } from './model';
 
/**
 * DataSource access interface
 * Asuuming network acces, all methods are asynchronous
 */
export interface DataSource {
  setHistory(history: History): Promise<void>;
  getHistory(): Promise<History>;
  
  setStepNumber(stepNumber: number): Promise<void>;
  getStepNumber(): Promise<number>;
}

 // DataSource Impl
 import type { History, Board } from '../../domain/model';
 import type { DataSource } from './dataSource';
 
 export class OnMemoryDataSourceImpl implements DataSource {
   history: History = [];
   stepNumber: number = 0;
   
   constructor() {
     const board = this.#createEmptyBoard();
     this.history.push({ board });
   }
   
   #createEmptyBoard(): Board {
     return Array(9).fill(null);
   }
   
   async setHistory(history: History): Promise<void> {
     this.history = history
   }
   
   async getHistory(): Promise<History> {
     return this.history
   }
   
   async setStepNumber(stepNumber: number): Promise<void> {
     this.stepNumber = stepNumber;
   }
   
   async getStepNumber(): Promise<number> {
     return this.stepNumber;
   }
 }

Main Layer

모든 구성요소를 묶어 하나의 애플리케이션으로 결합

Main Layer 설계

여러 레이어를 하나의 애플리케이션으로
Repository 구현을 생성하고 View에 의존성 주입
Repository는 modelController(custom hook)를 통해 useCase Layer로 전달
UseCase는 Repository를 사용
UseCase에서 RepositoryImpl를 생성하면 안됨
- 객체 생성은 Main Layer에서, 객체 사용은 UseCase Layer에서로 분리

  // Dependency Injection
const dataSource = new OnMemoryDataSourceImpl();
const repository = new RepositoryImpl(dataSource);

export function App() {
  return <TicTacTocView repository={repository} />
}

의존성 흐름의 위배

실제 애플리케이션은 제어 흐름이 항상 한 방향으로 흐르지 않는다.

UseCase의 비즈니스 로직이 Repository의 인터페이스를 사용
Repository에서 data layer에서 관리되는 데이터에 접근 등
이런 의존성 규칙 위반을 해결하기 위한 수단으로 의존성 역전을 사용

의존성 역전 (Dependency Injection)

interface - implement의 구조
인터페이스 설계에 기반으로 실제 구현체는 Data layer에서 정의
정의체는 상위 레이어에 있지만 구현체는 하위에 둠으로써 서로간 느슨한 결합을 통해서 의존성 역전을 구성할 수 있다.

의존성 파악 도구

코드의 의존성이 단방향으로 가리킬수 있는 의존성 규칙을 유지할 수 있는 도구(Lint와 같은)

Dependency-cruiser

소스파일을 분석, 파일간 의존성 검증하는 도구

rule을 검증
위반된 규칙을 텍스트/그래픽으로 표시
부수적으로 시각화된 다양한 출력 형식의 dependency graph를 생성

yarn add -D dependency-cruiser
npx depcruise --init

소스 코드 검증

npx depcruise src --include-only '^src' --config --output-type err-long

Dependency graph 생성

Graphviz 사용으로 의존성 그래프 생성

$ brew install graphviz

$ npx depcruise src --include-only '^src' --config --output-type dot|dot -T svg > dependency-graph.svg && open dependency-graph.svg

script 추가

위 명령어들은 자주 사용되므로 스크립트에 등록

"scripts": {
  "depcruise:validate": "depcruise src --include-only '^src' --config --output-type err-long",
  "depcruise:tree": "depcruise src --include-only '^src' --config --output-type dot|dot -T svg > dependency-graph.svg && open dependency-graph.svg"
}

Clean Architecture를 위한 Rule Custom

일반 규칙으로 감지하지 못하는 상황 1. Presentation에서 Data Layer를 참조하는 상황 (순환 참조가 아니므로 일반규칙에선 감지 못함)

Presentation Layer 의존성이 Domain으로 향하게끔 rule 설정

allowedSeverity: "error",
allowed: [
  {
    from: { path: "(^src/Presentation)" },
    to: { path: ["^src/Domain"] },
  }
]

But 다른 유효한 의존성도 not-in-allowed 로 표시된다.
allowed 규칙을 사용하는 경우 dependency-cruiser는 적어도 하나 이상의 규칙을 충족하지 않는 각각의 의존성에 대해 not-in-allowed 로 표시한다.
유효한 의존성을 명시적으로 모두 작성해주어야 한다.
번거롭지만, 리포지토리에 새 폴더를 추가할 때 마다 의존성을 설계하고 새 규칙을 추가하는 것이 좋은 습관

allowedSeverity: "error",
allowed: [
  {
    from: { path: "(^src/Main)" },
    to: {
      // "$1" is introduced from regular expression's "group matching"
      // You can reference the part method between brackets in "from"
      // string by using "$1" in "to".
      path: ["^$1", "^src/Presentation", "^src/Data", "^src/Domain"],
    }
  },
  {
    // Presentation other than Presentation/hook
    from: { path: "(^src/Presentation)", pathNot: "^src/Presentation/hook" },
    to: { path: ["^$1", "^src/Domain"] },
  },
  {
    // We want no hooks to depend on Presentation to make hooks independent
    // from any graphical presentation
    from: { path: "(^src/Presentation/hook)" },
    to: { path: ["^$1", "^src/Domain"] },
  },
  {
    from: { path: "(^src/Data)" },
    to: { path: ["^$1", "^src/Domain"] },
  },
  {
    from: { path: "(^src/Domain/Usecase)" },
    to: { path: ["^$1", "^src/Domain/Repository", "^src/Domain/Model"] },
  },
  {
    from: { path: "(^src/Domain/Repository)" },
    to: { path: ["^$1", "^src/Domain/Model"] },
  },
  {
    from: { path: "(^src/Data)" },
    to: { path: ["^$1", "^src/Domain"] },
  },
  {
    from: { path: "(^src/Domain/Model)" },
    to: { path: ["^$1"] },
  },
  {
  // Files outside of established folders (e.g. src/index.tsx) can reference
  // any files.
    from: { pathNot: ["^src/Main", "^src/Presentation", "^src/Data", "^src/Domain"] },
    to: {},
  }
]

큰 Repo의 의존성 시각화

상위 수준(폴더 기준)의 그래프 확인하여 wide하게 확인할 수 있다.

$ npx depcruise src --include-only '^src' --config --output-type ddot|dot -T svg > dependency-graph.svg && open dependency-graph.svg

의존성 검증을 git과 연동

여러 멤버가 같은 리포지토리에서 작업할 때 클린 아키텍처 의존성을 유지하기 어렵다.
변경사항을 적용*(커밋)할 때마다 의존성 크롤러를 실행해서 검증 (Husky)

$ npx husky-init && yarn
$ npx husky add .husky/pre-commit 'yarn depcruise:validate'

Previous모노로틱 아키텍처 NextLayered Architecture

Last updated 3 months ago