클린아키텍처: 계층형 아키텍처의 문제를 보완해보자.

1. 다시 보는 계층형 아키텍처

- 계층형 아키텍처는 소프트웨어를 구성하는 소스코드를 관심사에 따라 "계층"으로 분류한 구조이다.

- 계층형 아키텍처의 최대 관심사는 "관심사에 따른 계층 분리"이며, 일반적으로 다음과 같은 구조들이 제시된다.

presentation -> business(service / domain) -> data access(persistence) -> db

- 이러한 계층형 아키텍처는 다음과 같은 장점을 가진다.

• 계층별 관심사가 분리되기 때문에, 코드가독성과 유지보수성이 높다.
• 모듈 교체가 용이하다.
  • 예컨대, business 레이어에서만 사용하는 모듈을 교체할 때, 이에 따라 다른 계층에 미칠 사이드 이펙트가 현저히 적을 것이다.
• 테스트가 용이하다.
  • 각 계층은 관심사에 따라 분리되어 있으며, 직접적으로 맞닿은 계층이 아니면 의존관계가 없기 떄문에, 테스트 환경을 구성할 때, 그 계층의 환경만 고려하면 된다.

- 자세한 내용은 이전 포스팅을 참고하면 좋다.(계층형 아키텍처)

---

2. 계층형 아키텍처의 문제 그리고 클린 아키텍처의 등장

-  이러한 계층형 아키텍처는 "도메인"의 관점에서 다음과 같은 문제를 가지고 있다.

계층형 아키텍처는 그것의 구조로 인해, 소프트웨어가 핵심적으로 해결하고자 하는 문제영역으로서 도메인이 아니라, Data Access 계층, 즉 DB가 소프트웨어의 핵심이 될 수밖에 없다.

- 위와 같은 문제가 발생하는 이유는 계층형 아키텍처의 최하단 계층은 DB이기 떄문이라고 개인적으로 생각한다.

- 계층형 아키텍처의 일반적인 구조를 다시 보자면 이렇다.

presentation -> business(service / domain) -> data access(persistence) -> db

- DB에서 Column이 추가/삭제되거나, 혹은 DB가 다른 DBMS로 변경되는 등 DB 계층에서의 변경사항이 business 계층에 영향을 미칠 수밖에 없는 것이다. 물론, presentation 계층은 business 계층의 변경 사항에 영향을 받을 수밖에 없다.(하지만 이것이 방점이 아니다. 방점은 도메인이 DB에 영향을 받는다는 것이다!)

- DB가 소프트웨어의 핵심이 되는 것이 "문제"가 되는 이유는 다음과 같다고 생각한다.

1. 어쨋든, 소프트웨어가 해결하고자 하는 핵심은 "도메인"이고, DB, 프레임워크 등은 그 도메인을 수행하기 위한 기반 환경들인데, 도메인이 DB에 영향을 받는 것은 옳지않다.

2. 더욱이, DB가 아키텍처의 메인이 된다면, 아키텍처를 유지/보수, 확장하는 과정에서 영속성 계층과 도메인 계층의 구분이 모호해지는 지점이 발생할 수 있다(ORM을 활용함에 따라 더더욱).

3. 2번 이유로 인해, 경우에 따라서는 계층형 아키텍처의 본질이 흔들리게 된다.

- 이러한 계층형 아키텍처의 문제는 의존성 역전을 활용해서 해결될 수 있다.

- 클린 아키텍처는 의존성 역전을 활용해서 계층형 아키텍처의 문제를 해결하는 방식을 구조적으로 정립한 아키텍처인 듯 싶다. 

---

3. 클린 아키텍처

1) 개요

- 클린 아키텍처는 Robert C Martin이 제시한 아키텍처이다.(클린 아키텍처)

- 클린 아키텍처의 가장 근본적인 목표는 계층형 아키텍처와 마찬가지로 소프트웨어의 구성요소들을 계층에 따라 관심사를 분리하는 것이다.

- 클린 아키텍처의 구성요소들은 다음과 같다.

• Entities
  • 엔티티는 소프트웨어에서 문제 해결을 위해 핵심이 되는 업무 규칙들이 속하는 계층으로, 도메인이라고 할 수 있다.
  • 엔티티는 단순히 속성들로만 구성된 객체일수도, 속성과 메소드로 구성된 객체일 수 있다.
  • 엔티티 계층은 프레임워크, DB 등 어플리케이션을 구성하는 그 어떤 것들도 영향을 미쳐서는 안된다. 즉, 다른 계층들로부터 보호되어야 하는 계층이다.
• Usecase
  • 유즈케이스는 어플리케이션 수준의 업무 규칙들이 속하는 계층이다.
  • 유즈케이스는 어플리케이션 상에서 엔티티 간 데이터 통신을 관장하고, 또한 엔티티의 업무 규칙들이 어플리케이이션 상황에서 실행되도록 하는 코드들이 포함된다.
    • 예컨대, 소프트웨어에 두 가지 도메인이 있고, 어플리케이션 상에서 두 도메인을 모두 사용하는 상황이 있다면, 하나의 유즈케이스에서 두 도메인 엔티티의 업무규칙을 주입해서 업무규칙을 유즈케이스로 구현하는 것이다.
  • 이 때, 엔티티 업무 규칙들을 구현한 유즈케이스들은 각각 캡슐화되어 있다.
  • 유즈케이스는 엔티티와 마찬가지로 어플리케이션을 구성하는 외형적인 특징들, DB, 프레임워크 등에 영향을 받아서는 안된다. 
• Interface adapter
  • 인터페이스 어댑터는 외부에서 유입되는 데이터를 유즈케이스와 엔티티에서 사용하기 편한 방식으로, 또 반대 방식으로 데이터를 변환하는 것을 담당하는 계층이다.
  • 계층형 아키텍처에서 presentation에 속하는 controller와 같은 것이 이 계층에 속할 수 있다.
• Frameworks and drivers
  • 소프트웨어를 구성하는 세부 사항에 해당한다.
  • 소프트웨어에서 사용하는 프레임워크, 데이터베이스, 웹/앱 인터페이스가 이에 해당한다.

- 그리고 클린 아키텍처는 이것을 위해서, 아키텍처의 각 구성요소들은 의존성 규칙을 준수하는 형태로 구현되어야 한다고 한다.

- 의존성 규칙의 내용은 다음과 같다.

1. 아키텍처에서 내부계층은 소프트웨어의 원칙, 정책이 되어야 하며, 외부계층은 내부 계층을 구동하는 매커니즘이 된다.
2. 내부 계층의 그 어떤 것도 외부 계층의 내용을 파악할 수 없다. 즉, 내부 계층은 외부 계층에 의존해서는 안된다는 것이며, 외부 계층의 그 어떤 것도 내부 계층에 직접적으로 영향을 미쳐서는 안된다.

 

---

2) 클린 아키텍처에 따른 이익

- 클린 아키텍처를 통해 얻을 수 있는 이익은 핵심적으로 도메인과 비즈니스 로직을 중심으로 한 유지보수/확장이 가능하다는 것이라 생각한다. 구체적으로 다음과 같다.

1. 도메인/비즈니스 로직을 순수하게 보존하기 용이하고, 도메인이 중심이 된 개발을 하는 데 용이하다. 클린 아키텍처에서는 도메인 엔티티가 코어이기 떄문이다.
- 구체적으로, 도메인이 아키텍처의 가장 내부 계층, 즉 소스코드의 코어이기 때문에, 항상 도메인을 코드의 중심으로 두고 코드를 작성할 수 있다.
- 계층형 아키텍처는 ORM을 시작으로 DB 계층과 도메인 계층의 경계가 모호해질 수 있는 우려점이 있었다. 클린 아키텍처는 비즈니스 로직에 더욱 초점을 명확히 맞출 수 있는 구조라고 생각했다. 즉, 어플리케이션의 제반 여건들(DB, Framework 등)로부터 비즈니스 로직을 좀 더 보호할 수 있는 구조인 것이다.

2. 그래서 계층 간 관심사 분리가 뚜렷하다. 

3. 이에 따라, 유지보수성에서 이익이 발생한다.
- 예컨대, DB를 변경하거나, ORM을 변경하는 상황이 발생한다면, 비즈니스 로직이 들어있는 엔티티와 유즈케이스는 그것들로부터 독립되어 있기 때문에, DB와 ORM만 변경해주면 된다.
- 계층형 아키텍처에서는 상황에 따라 ORM을 변경하면 도메인 로직도 변경해줘야만 하는 상황이 발생할 수 있다는 우려점이 있었다. (물론 DB에 새로운 Column이 추가되는 건 도메인에도 변경사항이 존재할 수 있음을 의미할 수도 있을 것 같다.)

---

4. 참고해볼 만한 자료

- 클린 아키텍처를 NestJS 환경에서 적용한 사례이다. 코드 단에서 클린아키텍처를 이해하는데 도움이 되었다.

https://medium.com/@jonathan.pretre91/clean-architecture-with-nestjs-e089cef65045

Clean architecture with Nestjs

---

5. 참고자료

- https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

- https://medium.com/@jonathan.pretre91/clean-architecture-with-nestjs-e089cef65045

Clean architecture with Nestjs

- https://velog.io/@jay/common-it-is-easy-dip

쉽게 말하는, 의존성 역전하기

- https://techblog.woowahan.com/2647/

주니어 개발자의 클린 아키텍처 맛보기 | 우아한형제들 기술블로그