TIL
🌱 난 오늘 무엇을 공부했을까?
📌 The Clean Architecture
📍 Architecture란?
- 애플리케이션 아키텍처는 애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술
🔗 The Clean Architecture는 무엇인가?
- 관심사의 분리를 위한 아키텍처
- 소프트웨어를 계층으로 나누어 이러한 분리를 달성한다.
- 각각에는 비즈니스 규칙용 레이어와 인터페이스용 레이어가 하나씩 있다.
- 각 아키텍처는 다음과 같은 시스템을 생성합니다.
1. Independent of Frameworks. 아키텍처는 기능이 포함된 소프트웨어의 일부 라이브러리의 존재에 의존하지 않습니다. 이를 통해 시스템에 제한된 제약 조건을 가두지 않고 이러한 프레임워크를 도구로 사용할 수 있습니다.
2. Testable. 비즈니스 규칙은 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있습니다.
3. Independent of UI. UI는 시스템의 나머지 부분을 변경하지 않고도 쉽게 변경할 수 있습니다. 예를 들어 비즈니스 규칙을 변경하지 않고 웹 UI를 콘솔 UI로 교체할 수 있습니다.
4. Independent of Database. Oracle 또는 SQL Server를 Mongo, BigTable, CouchDB 또는 다른 것으로 교체할 수 있습니다. 비즈니스 규칙은 데이터베이스에 바인딩되지 않습니다.
5. Independent of any external agency. 실제로 비즈니스 규칙은 외부 세계에 대해 전혀 알지 못합니다.
🤔 The Dependency Rule
- 동심원은 소프트웨어의 다른 영역을 나타냅니다.
- 일반적으로 단계가 올라갈수록 소프트웨어의 수준이 높아집니다.
- 바깥쪽 원은 메커니즘입니다.
- 내부 원은 정책입니다.
이 규칙은 소스 코드 종속성이 안쪽만 가리킬 수 있다고 말합니다.내부 서클의 어떤 것도 외부 서클의 무언가에 대해 전혀 알 수 없습니다.우리는 외부 원의 어떤 것도 내부 원에 영향을 미치는 것을 원하지 않습니다.
🤔 Entities
- Entities encapsulate Enterprise wide business rules.
- 비즈니스 규칙을 캡슐화합니다.
- 엔터티는 메서드가 있는 개체이거나 데이터 구조 및 함수 집합일 수 있습니다.
외부에서 무언가가 변경될 때 변경될 가능성이 가장 적습니다.특정 애플리케이션에 대한 운영상의 변경은 엔터티 계층에 영향을 미쳐서는 안 됩니다.
🤔 Use Cases
- 이 계층의 소프트웨어에는 응용 프로그램별 비즈니스 규칙이 포함되어 있습니다.
- 엔터티 간에 데이터 흐름을 조정하고 해당 엔터티가 사용 사례의 목표를 달성하기 위해 전사적 비즈니스 규칙을 사용하도록 지시합니다.
- 이 레이어의 변경 사항이 엔터티에 영향을 미칠 것으로 예상하지 않습니다. 또한 데이터베이스, UI 또는 일반 프레임워크와 같은 외부 요소의 변경으로 인해 이 계층이 영향을 받을 것으로 예상하지 않습니다.
🤔 Interface Adapters
- 계층의 소프트웨어는 사용 사례 및 엔터티에 가장 편리한 형식에서 데이터베이스 또는 웹과 같은 일부 외부 기관에 가장 편리한 형식으로 데이터를 변환하는 어댑터 세트입니다.
- The Presenters, Views, and Controllers all belong in here
- 모델은 컨트롤러에서 사용 사례로 전달된 다음 사용 사례에서 발표자와 보기로 다시 전달되는 데이터 구조일 가능성이 높습니다.
🤔 Frameworks and Drivers
- 가장 바깥쪽 레이어는 일반적으로 데이터베이스, 웹 프레임워크 등과 같은 프레임워크와 도구로 구성됩니다. 일반적으로 이 레이어에는 안쪽으로 다음 원과 통신하는 글루 코드(프로그램의 요구사항 구현에는 기여하지 않지만, 본래 호환성이 없는 부분끼리 결합하기 위해 작동하는 코드) 외에는 많은 코드를 작성하지 않습니다.
- 이 네 가지 이상이 필요할 수도 있습니다.
- 그러나 종속성 규칙은 항상 적용됩니다.
- 소스 코드 종속성은 항상 안쪽을 가리킵니다.
- 내부로 이동함에 따라 추상화 수준이 높아집니다.
- 가장 바깥쪽 원은 낮은 수준의 콘크리트 디테일입니다.
- 내부로 이동함에 따라 소프트웨어는 더 추상화되고 더 높은 수준의 정책을 캡슐화합니다.
- 가장 안쪽의 원이 가장 일반적입니다.
🤔 Crossing boundaries
- 다이어그램의 오른쪽 하단에는 원 경계를 넘는 방법의 예가 있습니다.
- controller -> useCase -> presenters 실행
- 그들 각각은 useCase를 향해 안쪽을 가리킵니다. 우리는 일반적으로 Dependency Inversion Principle 을 사용하여 이 명백한 모순을 해결합니다.
- 예를 들어 Java와 같은 언어에서는 인터페이스와 상속 관계를 정렬하여 경계를 가로지르는 올바른 지점에서 소스 코드 종속성이 제어 흐름에 반대되도록 합니다.
예를 들어 useCase에서 presenters를 호출해야 한다고 가정합니다. 그러나 이 호출은 종속성 규칙을 위반하므로 직접 호출해서는 안 됩니다. 외부 서클의 이름은 내부 서클에서 언급할 수 없습니다. 그래서 우리는 내부 원에서 인터페이스(여기서는 useCase Output Port로 표시)를 호출하는 useCase를 갖고 외부 원의 presenters가 이를 구현하도록 합니다.
📍 결론
- 소프트웨어를 계층으로 분리하고 종속성 규칙 을 준수하여 본질적으로 테스트 가능한 시스템을 만들고 의미하는 모든 이점을 얻을 수 있습니다.
- 데이터베이스나 웹 프레임워크와 같이 시스템의 외부 부품이 더 이상 사용되지 않는 경우 최소한의 작업으로 이러한 사용되지 않는 요소를 교체할 수 있습니다.
I Am Groot