Architecture & Clean Architecture - part.2

이어서...

• 각각의 원들은 소프트웨어의 각기 다른 영역을 나타내고 있는데 바깥쪽의 레이어를 메커니즘(Mechanism)이라하고, 안쪽의 레이어를 정책(Policy)라고 한다. 그 이유는 클린아키텍처는 모든 소스코드의 의존성은 반드시 아우터에서 이너로 고수준으로 향해야 한다는 의존성 규칙을 가지고 있기 때문이다. 즉, 안쪽 레이어는 바깥족 레이어에 관해 전혀 알지 못하며 따라서 바깥쪽 레이어에 선언된 어떠한 이름도 참조할 수 없다는 말이다. 여기서 말하는 이름은 function, class, variable 등 이름이 붙은 모든 소프트웨어 엔티티들을 말한다.

🚶🏿‍♂️ <인사이드 아웃을 통한 추상화>

란 복잡한 문제에서 핵심만 간추리는 작업을 말한다.

:: 1. 3차원의 캐릭터

:: 2. 각지게 변화

:: 3. 분해

:: 4. 4차원

:: 5. 선으로 변화

:: 6. 탈출

• 클린 아키텍처에서는 추상화가 많이 될수록 고수준이라고 한다. 예를들면 <구역배달료를 구한다>라는 로직은 고수준, A구역에속한 배달건에 대한 배달료를 구한다는 것은 저수준에 해당한다. 몽말이냐면 고수준은 상위개념에 해당하고 저수준은 이러한 개념을 실제로 어떻게 구현할지에 대한 세부 사항에 해당하게 되는 것이다, 이에 따라 저수준인 가장 바깥쪽에 레이어 프레임워크에서 고수준의 가장 안쪽 레이어인 엔티티로 데이터를 전달한다.

• 클린 아키텍처는 크게 세개의 레이어 도메인, 어댑터, 인프라스트럭처로 나뉜다.
• 여기서 도메인레이어는 다시 엔티티(Entity)와 유즈케이스(Use Case)로 나뉜다.

:: Entity

• 엔티티는 비즈니스 로직들의 집합으로 메서드를 갖는 객체일 수도 있지만 데이터 구조와 함수의 집합일 수도 있다. 엔티티는 가장 일반적이고 고수준의 규칙을 하며 독립적이어야 하고, 특정 어플리케이션의 무언가가 변경되더라도 엔티티 계층에 대해서는 절대 영향을 주어서는 안 된다. 예를들면 대출에 10% 이자를 부과하는 것은 은행이 가진 규칙이다. 이것을 컴퓨터로 처리하느냐 종이로 서면으로 처리하느냐의 차이만 있을 뿐이다. 즉, 방법은 바뀔 수 있으나 본질은 변하지 않는다는 것이다.

:: Business Logic

• 그렇다면 비즈니스 로직이란건 무엇일까? 홈페이지 회원가입을 할 때를 생각해보면 유저는 아이디 중복 검사, 본인 인증, 비밀번호 재검사 등 validation과정을 거쳐야 한다. 회원가입 기능을 수행할 때 크게 두 가지 부분으로 나눌 수 있다. 하나는 중복 아이디가 있는지 없는지 검사하는 서버통신의 과정들이고 다른 하나는 유저에게 단순히 텍스트나 alert창으로 알려주는 것이다. 후자를 흔히 Presentation 영역 또는 View의 영역이라고 불리는데, 데이터를 단순히 보여주기만 하는 역할이다. 그리고 전자를 Model, 즉 데이터를 가공하고 로직을 통과시키는 부분이다. 전자의 Model을 비즈니스 로직이라고 한다. 이처럼 비즈니스 로직은 가장 핵심이 되는 요소를 말한다.

:: Use Case

• 유즈케이스란 내가 만들고자하는 시스템을 사용하는 클라이언트가 그 시스템을 통해 하고자 하는 것을 말한다. ㅇ예를들면 '영화관'이라는 서비스가 있다고 가정해보면 영화관에서 손님(클라이언트)은 '영화 예매'를 할 수도 있고, '예매 취소'를 할 수도 있고, '환불', '팝콘구매' 등을 할 수도 있다. 이 때, 이런 '영화예매', '예매취소', '환불', '팝콘구매' 등이 '영화관'이라는 시스템에 사용자가 요청할 수 있는, '영화관'의 Use Case이다. Use Case는 Entity에 의존하는 동시에 상호작용한다. 앞에서 말했다시피 영화, 손님, 비용 등은 엔티티(Entity)가 되는거고 손님이 영화를 예매하는 것은 유즈케이스(Use Case)가 된다.

• 해당 레이어의 소프트웨어는 시스템의 모든 유즈케이스를 캡슐화하고 구현하며 유즈케이스는 엔티티와의 데이터 흐름을 조정하고, 엔티티가 유즈케이스의 목표를 달성하도록 지시한다. 또 의존성 규칙에 의해 유즈케이스의 변경이 엔티티에 영향을 주어서는 안 되며 데이터베이스, UI, 프레임워크의 변경으로부터도 유즈케이스가 자유로워야 한다(영향을 받지 않아야 한다). 하지만, 애플리케이션의 조작에 대한 변경이 일어나면 유즈케이스에 영향을 미칠 수도 있다. 그리고 이들 또한 엔티티와 마찬가지로 바깥 계층에 대해 아무것도 알지 못한다. 다만, 이 계층에서는 바깥 계층에서 사용할 수 있는 Interface를 정의한다.

:: Domain Layer

• 유즈케이스와 엔티티를 합쳐 도메인 레이어라고 부르는데 도메인 레이어는 누구와도 의존성을 이루지 않는 독립적인 레이어이다. 이 레이어에서는 비즈니스와 관련된 로직을 담당하며 앱에서 사용할 Model과 각각의 Business Logic 단위를 나타내는 Use Case, Use Case의 실질적인 구현을 담당하게 할 Repository 인터페이스로 구성이 되어있다.

:: Interface Adaptor

• 인터페이스 어댑터는 domain과 infrastructure 사이의 번역기 역할을 수행한다. 즉, 바깥 또는 안쪽으로 전달되는 모든 데이터를 전달하고, 데이터를 전달받는 레이어에 용이한 형식으로 변환시켜주는 역할을 한다. View레이어로 전달되는 데이터를 문자열로 변경해 전달하는 것을 예로 들 수 있다. 프레젠터, 뷰, 컨트롤러는 모두 이 어댑터 레이어에 속한다.

:: Framework & Driver

• 인프라스트럭쳐는 가장 바깥쪽 레이어로 데이터베이스나 웹 프레임워크 등 일반적으로 프레임워크나 도구로 구성된다. 대개는 이 레이어에는 안쪽의 원과 통신할 연결 코드 이외에는 별다른 코드를 작성하지 않는다(이 때문에 인프라스트럭쳐 레이어는 도메인 레이어에 대해서 모른다 라고 할 수 있는 것이다). 네트워크, UI, 데이터베이스, 라이브러리와 프레임워크, 인아웃풋 장치 등이 이에 포함되고 이 레이어에 있는 것들은 빈번하게 변경되는 것이므로 추상화와 제어의 역전을 통해 안쪽 레이어들을 변경으로부터 안전하게 만들어야 한다(잘 짜여진 아키텍처에서는 인프라스트럭쳐가 변경되더라도 도메인은 변경되지 않기때문이다).

####::Adapter & Infrastructure

• 앞에 보았던 프레임워크와 드라이버가 인프라스트럭쳐 레이어가 되고 도메인 레이어와 인프라스트럭쳐 사이의 번역기 역할을 수행해주는 인터페이스 어댑터 부분이 어댑터 레이어로 분류된다.

####::교차경계

• Adapter에 해당하는 Presenter와 Controller가 상위 계층인 Use Case와 어떻게 소통하는지 나타내고 있다. 하지만 여기서 이상한점은 제어의 흐름(Flow of Control)을 보면 Controller → Usecase → Presenter로 흘러가는걸 알 수 있다. 고수준의 Use Case가 저수준의 Presenter를 참조하고 있는 상황이다.

• 이를 해결하기 위해서는 다음 두 상황을 고려해야 한다. 첫째 의존성 규칙을 지키기 위해서는 단순하고 고립된 형태의 데이터 구조를 사용해야 한다. DB형식의 데이터 구조 또는 Framework에 종속적인 데이터 구조가 사용되게 된다면, 이러한 저수준의 데이터 형식을 고수준에서 알아야 하기 때문에 의존성 규칙을 위반하게 된다.

• 둘째 Crossing boundaries. 이는 제어의 흐름은 원의 내부에서 외부로 향할 수 있는데, 이는 의존성 규칙에 위배되므로 의존성 역전의 원칙(DIP)을 이용하여 해결해야 한다는 말이다. 즉, 고수준에서 저수준에 직접 참조하게 될 때 Interface를 하나 둠으로써, 저수준의 세부사항을 알 필요없고 변동사항에도 영향을 받지 않게 된다.

• 그럼 위에서 말한 4개의 원이 아니면 안되는 것일까? 아니다. 이 원은 엉클밥이 단순히 컨셉을 전달하기 위한 수단이며 항상 4개일 이유는 없고 필요에 따라 더 많아질 수도 있다. 하지만 무슨 일이 있어도 소스코드 의존성은 항상 안쪽을 향하며 안쪽으로 갈수록 추상화와 정책의 수준은 높아지는 의존성 규칙이 적용된다.

• 이론상으로는 도메인은 수정되지 않아야 한다고 하지만 실제 현업에서는 프로젝트의 방향과 진행에 따라 언제든 수정을 한다.