클린 아키텍쳐란?
클린 아키텍쳐는 로버트.C 마틴 아저씨가 고안한 아키텍쳐이다.
블로그를 보니까 되게 대단한 아저씨 인게 클린아키텍쳐, 클린코드, SOLID 뭐 다 만든사람이다. 통칭 밥아저씨 라고 한다. (uncle bob.. 이름이 밥이 아닌데 왜? 그냥 닉네임인가..)
찾다보면 계속 이 아저씨가 나온다.. 😦
이 클린아키텍쳐는 마틴 아저씨가 여러 패턴을 보다보니 세부적으로 다르기만 할 뿐 공통된 목표가 보여서
"너네 이거 하려는 거지?" 하고 만들었다.
- 여러 패턴
- Hexagonal Architecture
- Onion Architecture
- Screaming Architecture
- DCI
- BCE
결국 아키텍처의 목표는 계층을 분리하고 관심사를 분리해서 기능이 추가되거나 수정되는 등의 유지보수를 쉽게 하기 위함이다.
결국은 유지보수다.
아래의 그림은 밥아저씨가 클린 아키텍처의 이해를 돕기 위해 그려준 그림이다.
각 4가지 영역으로 나뉘는데
핵심은 바깥원의 구역은 안쪽원의 구역을 의존하며 안쪽원의 구역은 바깥원의 구역을 알 수 없다.
아저씨가 말하길 코드를 짜다 보면 분명 더 많은 원이 필요할 것이라 각자의 바운더리를 지키기만 하면 원이 몇개든 상관이 없다고 한다.
각 원을 간단히 소개한다.
Enterpricse Business Rules
제일 안쪽의 구역이다.
Entities가 들어가게 되는데 완전 쌩 날것의 데이터가 들어간다고 보면 된다.
어떤 서비스의 정제되지 않은 정말 쌩 것의 데이터가 들어간다.
예를 들어 메모 라고 한다면 제목, 내용, 날짜 등이 들어갈 것인데 String, String, Double등으로 날짜 같은 것들도 정제되지 않은 것이 들어가는게 맞는 것 같다. (혼자 공부한 것이라 확실하지 않다.)
MVC, MVVM의 Model과 비슷하다.
Application Business Rules
use cases 쪽은 비즈니스 로직이 들어간다.
여기서 로직이란 메모를 저장한다. 메모를 생성한다. 와 같은 추상적인 로직을 구현해야한다.
추상적인 로직이기 때문에 내 생각에는 프로토콜로 추상화를 시켜 이를 채택하는 객체를 만들어서 로직을 넣는 것이 맞는 것 같다.
use case와 entities를 합쳐 Domain Layer라고 한다.
플랫폼이 변경되더라도 변경이 되지 않아야 한다.
콘크리트 같이 아주 단단해야 한다. 그렇기 때문에 최대한 날것으로 깎아 만드는 것이 중요한 것 같다.
domain layer에서 공부한 것을 조금 간략하게 적자면
Model, entities, translater, usecase 등이 있는데
entities와 usecase는 간단하게 설명했으니 넘어가고Model은 translater를 이용해서 entities로 변환이 가능하다고 한다.
내 생각엔 entities는 DTO같이 네트워크나 DB에 저장이 되는 쌩 날것이고
Model은 위의 메모 제목, 내용, 날짜 등에서 날짜포맷을 미국이면 월, 일, 년도, 한국이면 년도, 월, 일로 바꿔주어 String을 가진다거나 하는 translater를 통해 조금 변환된 친구를 가지는 것 같다.이후 데이터를 저장할 때는 entities로 바꿔서 저장하면? 되지 않을까? 🤔
translater가 양방향으로 변환이 가능하다면?
이런 로직이 컨트롤러같은 좀 더 바깥 구역에 있다면 플랫폼이 바뀌게 된다면 플랫폼 별로 로직을 바꾸어 주어야 하는 상황이 생긴다.
iOS에서는 플랫폼이 하나 밖에 없지만 UIKit과 SwiftUI 같은 느낌으로 플랫폼이 변하는 경우라 생각한다.
Interface Adapters
이제 여기 부분이 controller, presenter 부분인데 use case의 로직을 직접 실행해서 값을 가지고 뷰에 보여주는 부분이다.
MVVM이라면 ViewModel쪽일 것이고, MVC 라면 Model일 것이다 MVC에서는 Model이 로직을 가지기 때문에 M이다.
이제 여기를 통해서 web, UI등에 보여주는 것이다.
이 부분과 DB쪽을 묶으면 Data Layer라고 하는데 use case가 데이터베이스 쪽에 접근해서 직접 저장하고 사용하는 것이다. 여기 데이터 베이스에서 저장하는 entity는 원 가장 중간의 것과 같은데 그러면 원이 맞지 않는다.
아 어렵다 여기
내 생각에는 Layer라고 하는 각각의 원이 있지않을까 싶다.
Data Layer는 use case와 entity만 있는 것
Frameworks & Drivers
여기와 Interface 쪽을 합쳐서 Presentation Layer라고 하는데
View와 ViewModel을 합쳐서 말할 수 있다.
추가
옆쪽의 분홍색 화살표는 controller 단에서 usecase를 사용하다보면 usecase에서 presenter부분을 사용하게 되는 경우가 있는데 그러면 안쪽 구역에서 바깥쪽 구역을 알게되니 위배된다는 뜻이다
그럴경우 추상화한 녀석(protocol, interface)을 사용해서 접근하라는 뜻이다.
