ZarttiOS

그럼 가장 안쪽 Layer에서 바깥 Layer로는 전혀 이동이 불가능한가? Apdater는, “Domain과 Infrastructure 사이의 번역기 역할을 수행한다.” 라고 언급 했었다. 이 때 흐름은 Controller → Use case → Presenter로 흐르게 된다. 이처럼 제어의 흐름이 원의 내부에서 외부로 향하는 것을 Crossing Boundaries 라고 한다. 하지만 위 흐름을 그대로 따른다면 Dependency Rule을 위반하게 된다. High-level인 Use case는 Low-level인 Presenter를 의존해서는 안되기 때문이다. 그래서 의존성 역전 원칙(DIP)을 적용하게 된다. 의존성 역전 원칙이란, 고수준 모듈이 저수준 모듈을 의존하는 것이 아니라, 저수준 모듈이..

관심사 분리는 어떻게 할까? Layer Clean Architecture 에서는 관심사를 분리하기 위해 소프트웨어를 계층으로 나누고, 각 계층이 독립적이기 위해 Layer를 설정하였다. Infrastructure Infrastructure Layer는 UI, DB, API, Framework 등이 존재하는 영역. 이는 Domain에 비해 형태가 자주, 쉽게 바뀔수 있다. Domain Domain Layer는 Business Logic이 존재하는 영역. Business Logic은 Infrastruecture에 비해 잘 변하지 않는 안정된 영역. Robert C. Martin(Uncle Bob)은, 이 경계를 기반으로 Layer를 나누고, 관심사를 분리하는 규칙을 의존성 규칙(Dependency Rule)..

Business Rule(= Business Logic = Domain Logic) 컴퓨터 프로그래밍에서 실세계의 규칙에 따라 데이터를 생성, 표시, 저장, 변경 하는 부분. 유저의 입력(UI)과 DB(Local, Remote) 사이에서 발생한 데이터 교환을 위해 특정 알고리즘이나 규칙이 정의된 부분. Business Logic은 Client의 요구에 따라 변경될 수 있다. 그렇기 때문에 별도로 관리 될 필요가 있다. System Architecture 시스템의 구조, 행위, 뷰를 정의하는 개념 모델. 시스템의 목적을 달성하기 위해 각 컴포넌트가 어떻게 상호작용하고 정보가 교환되는지 설명. 다양한 Architecture들이 존재하지만 모두 하나의 목적을 가지고 있다. 바로, 관심사의 분리. 관심사 분리의..

클린 아키텍처 사용을 고민하게된 배경 Architcure 시스템을 구성하는 서브 시스템, 컴포넌트와 같이 구성요소 간의 관계를 관리하는 시스템의 구조 프로그램 내에서 큰 구조로 구성되어 다른 구성 요소들을 관리하는 역할 Design Pattern 소프트웨어 개발 분야에서 반복해서 나타나는 문제점를 쉽게 해결하기 위해서 과거의 소프트웨어 개발과정에서 발견된 설계의 노하우를 바탕으로 이후에도 사용하기 좋은 형태로 가공해 정리한 것 특정 유형의 문제를 해결하는 방법으로 소프트웨어 아키텍처보다는 조금 더 좁은 개념에 포함 즉, 디자인 패턴은 아키텍처에 포함된다. MVC ViewController는 크게 아래 두 가지 일을 한다. Data를 User에게 보여주는 역할 UI를 다루는 역할 하지만 위 두 가지는 아래..