Clean Architecture With Hexagonal Architecture (1)

Clean Architecture (클린 아키텍처)란?

---

• 헥사고날 아키텍처(Hexagonal Architecture), 또는 포트 어댑터 아키텍처(Ports and Adapters Architecture)라고 불리는 소프트웨어 아키텍처 중 하나입니다.
• 소프트웨어는 시간이 지날수록 복잡해지고 요구사항은 계속 변화합니다.
  • 개발자는 변화에 유연하게 대처할 수 있어야합니다.
  • 복잡한 소프트웨어를 빠른 시간안에 수정해야합니다.
    • 클린 아키텍처를 통해 이 문제를 해결하고자 합니다.

정책과 세부사항

• 소프트웨어 시스템은 두 가지 구성요소가 존재합니다.

• 정책 (Policy)

  • 모든 업무 규칙(Business Rules)과 업무 절차(procedures) 를 구체화
  • 고수준
    • 추상화된 개념
    • ex) 예시: 데이터를 저장한다, 구역 배달료를 구한다

• 세부사항 (Detail)

  • 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소
    • ex) 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크 등등
  • 저수준
    • 세부적인 개념
      • ex) RDB에 데이터를 저장한다, 폴리곤 구역에 속한 배달건에 대해 배달료를 구한다

• 클린 아키텍처의 목표는 세부사항이 정책에 무관하게 만들 수 있는 시스템을 구축하는 것입니다.

왜 클린 아키텍처가 필요한가?

• 언제 어디서 요구사항이 변할지 모릅니다.
  • 개발자는 항상 변화에 대응할 수 있어야 합니다.
  • 변경사항을 간단하고 쉽게 적용할 수 있어야합니다.
  • 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태에 있습니다.
    • 개발자는 복잡도와 의존성이 증가한 소프트웨어를 변경하는 것을 두려워하기 때문입니다.

로버트 C. 마틴의 책 클린 아키텍처 중에 이런말이 있습니다.

• 프로그램을 동작 하게 만들기는 그리 어려운 일이 아니다.
  • 하지만 제대로 만들기는 어렵다.
    • 제대로 만들게 되면 소수의 프로그래머만으로 프로그램이 지속적으로 동작하도록 만들 수 있다.
• 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는데 있다.
• 빨리가는 유일한 방법은 제대로 가는 것이다.

Layer

---

• Entities (Domain)
  • 도메인 계층
  • 하나 이상의 프로그램 간에 공유됨
  • 수명이 긴 객체
  • 재사용성이 높으므로 변경될 가능성이 낮은 객체를 가짐
• Use Cases (Application)
  • 애플리케이션 계층
  • 비즈니스 규칙을 포함한 계층
  • 외부 요소에 영향을 받지 않아야함
• Interface Adapter (Port)
  • 바깥 계층에서 사용하기 편리하도록 유즈케이스, 엔티티 계층에서 데이터를 변환
  • Controller, Presenter
• External Interfaces (Infrastructure)
  • 인프라 계층
  • 시간이 지남에 따라 구성이 변경될 수 있음
  • 엔티티 계층에 추상화 하여 도메인 계층에 영향을 주지 않고 인터페이스를 수정, 업데이트 가능
    • ex) DB, 웹 프레임워크, HTTP
      
      
      
• 모든 계층은 도메인에 의존하지만
  • 다른계층들은 서로 의존하지 않습니다.
• 이를 위해 핵심 비즈니스 로직은 중앙의 도메인 영역에 위치하며, 입력과 출력을 처리하는 포트와 어댑터를 통해 외부와 소통합니다.

요약

---

• 개발을 진행하다보면 이곳 저곳 섞여있는 의존도와 복잡도로 인해 소프트웨어의 변경에 난항을 겪을 때가 많습니다.
  • 이러한 아키텍처들을 통해 해결을 함과 동시에 요구사항의 변경과 유지보수에 용이한 아키텍처들을 활용함으로써 복잡도를 낮추는 방법을 알아보았습니다.
• 외부 세부사항에 의존하지 않습니다.
  • 테스트하기 쉽고 변경하기 쉬워집니다.
  • 고수준 정책 에만 의존하기에 저수준(구현체)에 문제가 되는 부분만 수정하기 용이합니다.

마무리

---

• 해당 아키텍처가 ‘100% 옳다’ 라는 것에는 동의하지는 않습니다.

  • 단점에도 보았듯이 실제 구현할때 복잡도가 올라갑니다.
  • 과한 추상화, 중복인것 같지만 거짓 중복인 것 같은 인터페이스들 등 단순하게 구현하기 어려워집니다.

• 상황에 따른 적절한 아키텍처를 적용해야 합니다.

  • 하지만
    • 그 이전에 좋은 아키텍처는 무엇인지
    • 의존성을 제거하고 변경하기 쉬운 소프트웨어를 어떻게 만드는지에 대해 알아 보는 것은 필요합니다.

• 다음은 예시를 통해 실제 아키텍처를 구현해 보는 글을 작성하고자 합니다.

참고

---

• 책 클린 아키텍처
• 주니어 개발자의 클린 아키텍처 맛보기: https://techblog.woowahan.com/2647/