[클린 아키텍처] 6부. 세부사항

출처 : yes24

 

 

🍊 데이터베이스는 세부사항이다.

---

데이터베이스는 세부사항이고, 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.

• 아키텍처와 데이터베이스의 관계는 건물로 비교하면 건물의 아키텍처와 문 손잡이의 관계와 같다.
• 체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요하지만, 기술과 시스템은 중요하지 않다.

 

🍒 데이터베이스 시스템은 왜 널리 사용되는 걸까?

-> "디스크(저장소의 중심)" 때문이다.

-> 데이터가 많아짐과 동시에 데이터를 읽는 "속도"는 중요했다. 

     시간 지연을 완화하기 위해 색인, 캐시, 쿼리 등 최적화가 필요했고, 이런 것을 제공해주고 데이터 접근 및 관리 시스템이         나오게 된 것이다.

 

🍒 데이터베이스 시스템은 왜 세부사항인 걸까? 

- 데이터베이스는 그저 매커니즘에 불과하며 데이터를 이리저리 옮길 때 사용할 뿐이다.

- 실제로 데이터를 장기적으로 저장하는 공간에 지나지 않는다. 

 

 

 

 

🍊 웹은 세부사항이다.

---

GUI는 세부사항이고, 웹은 GUI이다. 따라서, 웹은 세부사항이다.

• 아키텍트라면 세부사항을 핵심 업무 로직에서 분리된 경계 바깥에 두어야 한다.

 

🍒 웹이라면 예외가 있을 수도 있지 않을까?

- 웹은 GUI지만, 너무 특이하고 다채롭다. (JS의 유효성 검증, Drag&Drop, AJAX 호출, 위젯, 가젯 등)

   웹에서 장치 독립성이라는게 비현실적이라고 주장할 수 있다.

   하지만, UI와 애플리케이션 사이에는 추상화가 가능한 또 다른 경계가 존재한다.

   

 

 

 

🍊 프레임워크는 세부사항이다.

---

가능한 한 오랫동안 아키텍처 경계 너머에 두자

• 프레임워크를 사용하는 당신은 프레임워크에 큰 헌신을 해야되지만, 프레임워크 제작자는 아무것도 하지 않는다.
• 한 번 결합하면, 이를 깨기 어렵고, 이렇게 됨을 프레임워크 제작자는 원한다. (본인이 만든것이 효과적임을 검증하는 최고의 방식이니까..)

 

🍒 위험요인

1) 프레임워크의 아키텍처는 그다지 깔끔하지 않은 경우가 많다.

2) 초기 기능을 만드는 데 도움이 될 것이지만, 제품이 성숙해지면서 제공하는 기능과 틀을 벗어나게 될 것이다.

3) 프레임워크는 도움되지 않는 방향으로 진화할 수 있다. 

4) 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수 있다. 

 

 

🍒 해결책

- 프레임워크를 사용할 수는 있다. 하지만, 결합해서는 안되고 적당한 거리를 두자.

- 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면, 거절하자.

- 대신 proxy를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 proxy를 위치시켜라. 

 

 

 

 

🍊 사례연구 : 비디오 판매

---

🍒 유스케이스

단일 책임 원칙에 따르면 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다.

신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다.

 

🍒 컴포넌트 아키텍처

뷰, 프레젠터, 인터랙터, 컨트롤러로 분리된 분할 방법을 확인할 수 있다.

또한 대응하는 액터에 따라 카테고리를 분리했다는 사실도 확인할 수 있다.

 

🍒 의존성 관리

제어흐름은 위 그림에서 오른쪽 -> 왼쪽으로 이동한다.

입력 -> 컨트롤러 ->  인터랙터 -> 결과 -> 프레젠터 -> 화면

• 프레젠터 : 결과의 포맷을 변경
• 뷰 :  화면에 표시한다.

모든 의존성은 경계선을 한 방향으로만 가로지르는데, 항상 더 높은 수준의 정책을 포함하는 컴포넌트를 향한다.

 

 

🍊 빠져 있는 장

---

최적의 설계를 했더라도, 구현 전략에 얽힌 복잡함을 고려하지 않으면 설계가 순식간에 망가질 수 있다. 

• 설계를 어떻게 해야 원하는 코드 구조로 매핑할 수 있을지, 코드를 어떻게 조직화할지, 런타임과 컴파일타임에 어떤 결합 분리 모드를 적용할지를 고민하라.

 

예시 : 온라인 서점을 구축하고 있으며, 고객이 주문 상태를 조회할 수 있어야 한다는 유스케이스를 구현해야 한다고 해보자.

1) 계층기반 패키지

• 프로젝트 초반, 설계를 할 때 적합하다.
• 하지만, 좀 더 구체화되고 커진다면 코드를 담기엔 부족하다.

 

2) 기능 기반 패키지

• 서로 연관된 기능, 도메인 개념, 또는 수직의 얇은 조각으로 코드를 나누는 방식
• 인터페이스, 클래스 모두 동일하지만, 하나의 자바 패키지에 포함되어 있는 구조

 

 

3) 포트와 어댑터

  

 

 

 

• 코드 베이스는 "내부", 인프라는 "외부"
• 내부 : 도메인 개념을 모두 포함
• 외부 : 데이터베이스, 서드 파티 통합
• 주요 원칙 : 외부가 내부에 의존하며, 절대 그 반대로는 안된다

 

 

 

 

 

 

 

 

 

 

여기서, com.mycompany.myapp.domain 패키지가 "내부"이며,

나머지 패키지는 모두 "외부"이다. 

 

 

- 의존성은 내부에서만 흐르는 것을 주목하자. 

 

 

 

 

 

 

 

 

 

 

 

 

 

4) 컴포넌트 기반 패키지

 

 

 

 

🍒 완화된 계층형 아키텍처

> 여전히 의존성 화살표는 아래를 향하고 있지만, 몇몇 유스케이스에서는 Controller가 Service를 우회하고 있다.

    즉, 인증된 접근만을 허용하는 일을 업무 로직이 책임지고 있고, 해당 로직은 바람직하지 못하다. 

 

> 필요한 아키텍처 원칙

    웹 컨트롤러는 절대로 레포지토리에 직접 접근해서는 안된다.

   

 

> 필자는 요런 원칙들을 컴파일러를 사용해서 아키텍처를 강제하는 방법을 선호한다.

 

 

 

 

 

 

 

 

🍒 주문 조회하기 유스케이스 (컴포넌트 기반 패키지)

큰 단위의 단일 컴포넌트와 관련된 모든 책임을 하나의 자바 패키지로 묶는다.

 

이 접근법은 서비스 중심적인 시각으로 소프트웨어 시스템을 바라보며,
MSA가 가진 시각과도 동일하다.

 

컴포넌트 기반패키지는 사용자 인터페이스를 큰 단위의 컴포넌트로 분리한다.

 

'업무로직'과 영속성 관련 코드는 하나의 컴포넌트

 

컴포넌트는 배포 단위이고 시스템의 구성요소로 배포 수 있는 가장 작은 단위이다.

 

자바의 경우 jar가 컴포넌트이다.

 

 

컴포넌트 기반 패키지 접근법의 주된 이점 : Orders와 관련된 무언가를 코딩할 때,
오직 OrderComponent만 둘러보면 된다는 점이다.

 

 

 

5) 조직화 vs 캡슐화

자바 애플리케이션에서 모든 타입을 public으로 지정한다면, 패키지는 단순히 조직화를 위한 폴더구조가 되어 캡슐화를 위한 메커니즘이 될수 없다. 

 

 

5-1. public 지시자를 과용하면 이 장의 앞에서 제시한 네 가지 아키텍처 접근법은 본질적으로 같아진다.

본질적으로 같아지는 예

 

화살표들이 모두 동일한 방향을 가리킨다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5-2. 접근 지시자를 적절하게 사용하면 타입을 패키지로 배치하는 방식에 따라 접근할 수 있는 정도가 크게 달라진다.

1. 계층기반 패키지

> OrdersService 인터페이스와 OrdersRepository 인터페이스는 외부의 패키지로부터 자신이 속한 내부로 들어오는 의존성이 존재하므로 public으로 지정해야 한다.

반면 OrdersServiceImpl와 JdbcOrderRepository 구현체는 protected로 더욱 제한된다. 

 

2. 기능기반 패키지

> OrderController가 유일한 통로이므로 public. 

 

3. 포트와 어댑터

> OrderService와 Orders : public

 

4. 컴포넌트 기반 패키지

> OrderController, OrdersComponent

 

 

6) 다른 결합 분리 모드

소스코드 의존성 분리는 프로그래밍언어가 제공하는 방법 외에도 자바 OSGi나 자바9에서 제공하는 모듈 시스템으로 분리할 수 있다.

 

포트와 어댑터로 예로들면 소스코드 트리를 만들 수 있다. (이상적인 방법)

1. 업무와 도메인용 소스 코드 : OrderSerivce, OrdersServiceImpl, Orders
2. 웹용 소스 코드 : OrdersController
3. 데이터 영속성용 소스 코드 : JdbcOrderRepository

2, 3번 두 소스 트리는 컴파일 시점에서 업무와 도메인용 소스코드에 의존성을 가지며 업무와 도메인용 소스코드는 웹, 데이터영속성 코드에 대해 알지 못한다.

 

 

더 간단한 방법 

도메인 코드 : "내부" / 인프라 코드 : "외부"

인프라 : 도메인에 대해 컴파일시점에 의존성을 가진다.

단점 : 안티패턴

 

즉, 특정영역(인프라 코드중 웹 컨트롤러 부분)이 애플리케이션의 다른 영역에 있는 코드를 도메인 코드를 통하지않고 직접 호출할 수 있다. 적절한 접근 지시자 적용을 잊어버렸다면 더욱 막기 힘들다.

 

 

 

 

 

 

 

 

 

참고 서적

• http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9788966262472