TODO App, Weather App ... 이런 앱의 메인 기능을 뭘까? TODO, Weather이다. 프로그램의 핵심기능을 Use case라 하자. 이런 앱을 만들때 어떻게 설계해야할까?
Use case를 중심으로 설계해야 한다.
Use case는 비즈니스 로직을 담는데, 이게 바뀌지 않는 이상 Use case를 수정하는 일은 없도록 해야한다. 따라서, 비즈니스 로직을 바뀔 수 있는 모든것으로부터 분리해야한다!
예를 들어, Buy Goods라는 Use case가 있다.
1. 구매자의 구매요청
2. 판매자가 구매요청 정보 수집
3. 판매자가 구매자에게 정보를 줌(가격, 배송일자 등)
4. 구매자가 구매승인
...
위 단계 중 어느 과정에도 platform, DB process 등 이런 정보는 전혀 없다. 이렇게 관심사를 분리해 Use case에 집중하는 "클린 아키텍처"에 대해 알아보자
일단 설계의 중심이 될 Use case가 있다. 그리고 data 및 재사용 가능한 로직을 포함한 Entity를 만든다. 그럼 Application, DB 등은 Use case와 Entity에 직접적으로 접근하면 될까?
안된다. 그렇게 하면 외부세계(Application, DB 등)의 변경이 Use case에 영향을 미친다. 따라서, Use case와 외부세계 사이를 느슨하게 결합시켜주는 interface가 필요하다. 이걸 Interface adapter라고 하자.
이렇게 구성하면 비즈니스 로직을 모든것으로부터 분리했다고 할 수 있을까? 비즈니스 로직이 외부세계에 대한 참조를 갖고있다면? 그래서 의존성 법칙(The Dependency Rule)을 적용한다. 이 법칙은 위 Frameworks & Drivers -> Interface adapters -> Use cases -> Entities 방향으로 의존할 수 있다는 법칙이다. 근데 개발하다보면 꼭 그 반대로 호출(내부 -> 외부)이 필요한 상황이 있다. 그런 경우엔 외부클래스의 상위타입인 인터페이스를 둬(DIP) 이를 통해 의존성을 주입하는 방식으로 해결한다. 이렇게 Crossing boundaries 방식으로 구현하게 되면 저수준(외부)의 세부사항을 알 필요 없고 변동사항에도 영향을 받지 않게 된다!
ref. 도서출판 인사이트
클린 아키텍처란, 아키텍처의 청사진으로 모바일부터 백엔드까지 모든 소프트웨어에 일반적으로 필요한 내용을 담고 있으며, 각 계층을 어떻게 나누고 어떤 요소로 구성할 것인가에 대한 원칙들을 알려준다.
https://www.youtube.com/watch?v=5eOYb0Yvqh0
https://medium.com/@justfaceit/clean-architecture%EB%8A%94-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%84%EC%99%80%EC%A3%BC%EB%8A%94%EA%B0%80-1-%EA%B2%BD%EA%B3%84%EC%84%A0-%EA%B3%84%EC%B8%B5%EC%9D%84-%EC%A0%95%EC%9D%98%ED%95%B4%EC%A4%80%EB%8B%A4-b77496744616
https://k-elon.tistory.com/38