클린아키텍처

Gooreum·2021년 11월 5일
0

클린아키텍처

목록 보기
22/33

관심사 분리

  • 수많은 시스템 아키텍처 아이디어가 있지만 그들의 공통점은 '관심사의 분리'다.
  • 모두 소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성할 수 있었다.
  • 각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를 반드시 포함한다.
  • 이러한 아키텍처들의 특징은 다음과 같다.
    • 프레임워크 독립성
    • 테스트 용이성
    • UI 독립성
    • 데이터베이스 독립성
    • 모든 외부 에이전시에 대한 독립성

의존성 규칙

이미지 출처 : https://hwannny.tistory.com/41

💡 소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.
  • 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙이다.
  • 외부 원에 위치한 어떤 것도 내부의 원에 영향을 주지 않아야 한다.

엔티티

  • 엔티티는 핵심 업무 규칙을 캡슐화 한다.
  • 엔티티는 메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합일 수도 있다.
    • 엔티티는 인터페이스나 추상 클래스 형태일 것이라 생각했는데, 의외임..
  • 기업의 다양한 애플리케이션에서 엔티티를 재사용할 수만 있다면, 그 형태는 그다지 중요하지 않다.
  • 엔티티 게층은 절대 다른 외부의 요인(운영 관점 포함)으로 부터 영향을 받아서는 안된다.

유스케이스

  • 애플리케이션에 특화된 업무 규칙을 포함한다.
  • 유스케이스 계층의 소프트웨어는 시스템의 모든 유스케이스를 캡슐화하고 구현한다.
  • 유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끈다.
  • 운영 관점에서 애플리케이션이 변경된다면 유스케이스가 영향을 받을 수 있다.

인터페이스 어댑터

  • 인터페이스 어댑터 계층은 일련의 어댑터들로 구성.
  • 어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환한다.
  • GUI의 MVC 아키텍처 모두를 포함하며, 프레젠터, 뷰, 컨트롤러는 모두 인터페이스 어댑터 계층에 속한다.
    • 지금까지 내가 알고 있던 디자인패턴(MVC, MVVM, MVP등)들은 단순히 인터페이스 어댑터 계층만을 지칭하고 있었던 것인가?
  • 이 계층에 속한 어떤 코드도 DB에 대해 알아선 안 된다.
  • 이 게층에서는 데이터를 외부 서비스와 같은 외부적인 형식에서 유스케이스나 엔티티에서 사용되는 내부적인 형식으로 변환하는 또 다른 어댑터가 필요하다.

프레임워크와 드라이버

  • 이 게층에서는 데이터베이스나 웹 프레임워크 같은 프레임워크나 도구들로 구성된다.
  • 안쪽 원과 통신하기 위한 접합 코드 외에는 특별히 더 작성해야 할 코드가 그다지 많지 않다.
  • 이 게층은 모든 세부사항이 위치하는 곳이다.

원은 네 개여야만 하나?

  • 반드시 그러한 것은 아니지만 중요한 것은 의존성 규칙을 지켜야 한다는 것이다.
  • 소스 코드 의존성은 항상 외부에서 내부로 향해야 한다.
  • 안쪽으로 이동할수록 추상화와 정책의 수준이 높아져야 한다.
  • 바깥은 세부사항으로 구성 되어야 한다.

경계 횡단하기

이미지 출처 : https://hwannny.tistory.com/41

  • 제어흐름은 컨트롤러에서 시작해서, 유스케이스를 지난 후, 프레젠터에서 실행되면서 마무리된다.
  • 소스코드 의존성은 유스케이스를 향해 안쪽으로 가리킨다.
  • 예를 들어 유스케이스에서 프레젠터를 호출해야 한다면 유스케이스가 내부 원의 인터페이스(유스케이스 출력 포트)를 호출하도록 하고, 외부 원의 프레젠터가 그 인터페이스를 구현하도록 만든다.
  • 동적 다형성을 이용하여 소스 코드 의존성을 제어흐름과는 반대로 만들 수 있고, 이를 통해 제어흐름이 어느 방향으로 흐르더라도 의존성 규칙을 준수할 수 있다.

경계를 횡단하는 데이터는 어떤 모습인가

  • 경계를 가로지르는 데이터는 기본적인 구조체나 간단한 데이터 전송 객체등 원하는 대로 고를 수 있다.
  • 다만, 데이터 구조가 어떤 의존성을 가져 의존성 규칙을 위배하게 되어서는 안된다.
  • 예를 들어 데이터베이스가 처리하기 편리한 포맷인 행(row)구조가 경계를 넘어 내부로 그대로 전달되어서는 안된다.
  • 경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기에 가장 편리한 형태를 가져야만 한다.

전형적인 시나리오

  • 모든 의존성은 경계선을 안쪽으로 가로지르며, 의존성 규칙을 준수한다.
profile
하루하루 꾸준히

0개의 댓글