이 기사는
Clean Architecture 전문가에게 배우는 소프트웨어의 구조와 설계
초학자가 읽고 알았던 것을 쓰고 있으므로, 자세히 알고 싶은 사람에게는 도움이되지 않습니다.

깨끗한 아키텍처

그림 1

위의 그림은 다음을 단일로 실행 가능한 아이디어를 통합한 것이다.
- 프레임워크 독립(기능이 가득한 소프웨어는 라이브러리에 의존하지 않는다. 그래서 시스템은 프레임워크에 묶이지 않고 툴로 사용)
- 테스트 가능(비즈니스 규칙은 UI나 데이터베이스 등이 없어도 테스트 가능)
- UI 독립적 (UI는 시스템의 다른 부분을 변경하지 않고도 쉽게 변경할 수 있음)
- 데이터베이스 독립적 (DB 대체 가능. 비즈니스 규칙이 데이터베이스에 묶여 있지 않음)
- 외부 에이전트 독립적 (비즈니스 규칙은 외부 세계의 인터페이스에 대해서도 아무 것도 모른다)

종속성 규칙

도 1은 원의 중심에 가까울수록 소프트웨어 레벨이 증가한다.
원의 외측이 구조. 안쪽은 방침.
클린 아키텍처를 작동시키는 가장 중요한 규칙은 종속성 규칙입니다.
"소스 코드의 의존성은 안쪽으로 향해야 한다"
이다

엔티티

기업 전체의 가장 중요한 비즈니스 규칙을 캡슐화한 것.
가장 일반적이며 최상위 레벨 규칙을 캡슐화합니다.
외부가 변화해도 변할 가능성은 낮다.

사용 사례

응용 프로그램 특정 비즈니스 규칙이 포함되어 있습니다.
시스템의 모든 사용 사례가 캡슐화되고 구현되었습니다.
입출력하는 데이터의 흐름을 조정하고 유스 케이스의 목표를 달성할 수 있도록 엔티티에 가장 중요한 비즈니스 규칙을 사용하도록 지시한다.

인터페이스 어댑터

유스 케이스나 엔티티에 편리한 퍼머트로부터, 데이타베이스나 웹등의 외부 에이전트에 편리한 포맷에 데이터를 변환하는 어댑터.

프레임워크 및 드라이버

프레임 워크와 도구 등.

그림에없는 것은,,,?

그림에 나와 있지 않은 것도 문제는 없다.
그러나 의존성 규칙은 항상 적용됩니다.

안쪽에서 바깥쪽을 부르는 방법?

유스 케이스에서 발표자를 호출해야 할 때 생각합니다.
의존성의 규칙을 위반하기 때문에, 직접은 부를 수 없다.
발표자가 유스 케이스 출력 인터페이스를 구현.
그 인터페이스를 사용하면 유스 케이스 → 발표자를 만들 수 있습니다.

경계를 넘는 데이터의 형태는?

의존성을 갖지 않도록 독립된 단순한 데이터 구조인 것이 중요하다.
내부가 외부 데이터를 형식을 알면 종속성 규칙을 위반하기 때문에 내부 원에 편리한 형식으로 만듭니다.