얘를 공부하지 않고.. 고오급 수준의 코드를 이해하려 하니.. 하나도 이해가 되지 않는다는 것을 깨달아버렸읍니다… 여기서 usecase의 개념이 나왔는데, 이놈이 날 너무 괴롭혔거든…
이분께서 개발하시는 동안, 여러 아키텍쳐를 잘 살펴보시니, 유사한 점이 몇개 눈에 띄셨다고 함!
위의 두개의 공통점을 따라간 아키텍쳐는 어떤 소프트웨어를 뱉어내느냐,
<aside> 💡 ✅ Independent of Frameworks ➡️ 아키텍쳐는 소프트웨어 라이브러리의 존재에 의존하지 않음
✅ Testable ➡️ 비즈니스 로직은 UI, DB, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있음
✅ Independent of UI ➡️ UI는 시스템을 변경하지 않고도 쉽게 변경 가능(비즈니스 로직을 바꾸지 않고 웹 UI를 콘솔 UI로 변경하는 등)
✅ Independent of Database ➡️ 비즈니스 로직이 DB에 바인딩 되지 않음
✅ Independent of any external agency ➡️ 비즈니스 로직은 외부세계. outside world에 대해 전혀 알지 못함
</aside>
그래서 이런 다양한 아키텍쳐를 단일 아이디어로 통합하길 원했고, 이렇게 해서 나온 것이 바로 clean architecture임!
이제 이 그림을 이해해볼 차례!
이 아키텍쳐를 작동시키는 가장 우선적인 규칙은 Dependency Rule임
규칙은 간단하게 말하면 세가지임
<aside> 💡 ✅ 소스코드 종속성은 안쪽으로만 향할 수 있음(안쪽을 향해서만 의존할 수 있음) ✅ inner circles안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음 ✅ 특히, outer circles에 선언된 이름은 inner circles에서 언급해서는 안됨(함수, 클래스 등등)
</aside>