Clean Architecture
"소프트웨어를 계층으로 나눔으로써 관심사를 분리한다" 라는 아이디어를 기반으로
로버트 C. 마틴 선배님의 The Clean Architecture 의 포스팅이 있습니다.
2년전...
저는 Android 를 개발하면서 Clean Architecture 를 처음 접했으며 여기에서 많은 영향을 받았습니다.
아래 그림은 Clean Architecture 를 도식화한 그림입니다.
여러 Layer 로 나누어져있으며 각각의 역할을 담당하고 있다라는 수준으로만 이해하였습니다.
현재
마틴 파울러 저 엔터프라이즈 애플리에키션 아키텍처 패턴을 읽으며 첫장부터 Layering 에 대한 이야기가 나옵니다.
Layering
계층화 (layering) 은 복잡한 소프트웨어 시스템을 분할하는데 사용하는 일반적인 방법입니다.
(OSI 7계층, TCP/IP 4계층은 대표적으로 알려져있는 계층화 패턴의 예입니다.)
계층화는 아래와 같인 장점과 단점을 가지고 있습니다.
| 장점 | 단점 |
|
다른 계층에 정보없이도 단일 계층으로 하나의 일관된 계층으로 이해 (하나의 계층은 하나의 역할만 수행합니다. SOLID 원칙중 SRP 에 해당되는 내용인 것 같습니다. )
|
캡슐화되지 않음 (가장 안쪽에 계층이 변경되면 그 여파가 상위 계층에 미칩니다.) |
|
동일한 역할을 하는 다른 계층이 대체할 수 있다. (Presentation 은 다른 Presentation로 대체 가능합니다.)
|
계층이 많으면 성능이 저하된다. (Mapper 각 계층에서 다른 계층으로 통신할때 데이터를 변환할 필요가있습니다.) |
|
계층간 의존성을 최소화 (상위 계층은 하위 계층을 의존합니다. UI -> Presentation / Presentation -> Domain / Domain -> Data) |
|
|
계층은 표준화가 된다 (UI, Presentation, Domain 과 같이 표준으로 정의됩니다.) |
|
|
여러 다른 상위 계층에서 사용할수있다. (재사용성) |
Clean Swift (VIP)
각 계층에 대한 자세한 소개는 생략합니다.
Dejan Atanasov 는 HackerNoon Clean Swift 의 포스팅을 하였습니다.
Bob 아저씨의 Clean Architecture 이해를 바탕으로 iOS 에서 사용되는 Swift 언어를 통해 Clean Swift 를 코드로 녹여내었습니다.
Clean Swift 의 자세한 내용은 여기를 확인해주세요.
DDD(Domain driven Development) Context boundaries?
이 부분은 추가적인 설명 내용이므로 읽지 않으셔도 무방합니다.
DDD(Domain driven ) Context boundaries 에 대해 자세히 알고 싶으신 분들은 여기를 확인해 주세요.
Clean Architecture 의 단점 중 "계층이 많으면 성능이 저하된다." 는 Context Boundaries 와 같은 문맥으로 이해할 수 있습니다.
- Sales 가 바라보는 관점의 Customer
- Support 가 바라보는 관점의 Customer
Support 에서는 Customer 가 아닌 다른 이름을 사용할 수도 있습니다.
경계안에서 해석되는 Context 가 중요합니다.
여기까지 오셨다면 눈치채신분들도 계셨을 것입니다.
Clean Architecture 에서도 마찬가지로 경계가 존재합니다.
| Layer | Context boundaries |
| UI | UI 데이터 |
| Presentation | 사용자 인터페이스 표시 데이터 |
| Domain | 요구사항에 따른 데이터 |
| Data | DataSource(Remote, Cache) 로 부터 받은 데이터 |
결론
우리는 Clean Architecture 주제에 대해 토론을 진행하면서 많은 이야기들을 하였습니다.
- Rx 의 의존성이 널리 퍼진다.
- Closure 를 활용하여 헐리우드 원칙을 달성해야한다.
- Clean Swift에서 TDD 를 하지 않으면 반을 잃은것이다.
Clean Architecture 의 계층이 너무 많으면 오히려 비효율적이란 생각도 가지고 있지만
"코드의 일관성을 위해서 계층을 유지해야 한다" 라는 의견도 있었습니다.
결국엔 팀내에 균형, 코드의 균형의 조화를 이루어야 한다는 결론에 이르게 되었습니다.
우리는 "무조건 패턴이 좋다" 라는 인식보다는 균형을 잡기 위해 노력해야 한다는 것을 깨달았습니다.
참조:
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
https://github.com/Clean-Swift/CleanStore
https://hackernoon.com/introducing-clean-swift-architecture-vip-770a639ad7bf
https://medium.com/@seungh93/swift-clean-swift-1-e618aeb5b32e
https://github.com/bufferapp/clean-architecture-components-boilerplate
'iOS > 스몰토크' 카테고리의 다른 글
| [스몰토크] Swift Stubbing 통합테스트 (1) | 2019.11.26 |
|---|---|
| [스몰토크] TDD? 테스트코드? (0) | 2019.11.25 |
| [스몰토크] WKWebView 와 통신 어떤것이 적절할까? Scheme VS Bridge (0) | 2019.11.20 |
