• 시스템 아키텍처와 관련된 여러 가지 아이디어를 봐왔다
• 위의 아이디어들의 목표는 모두 관심사의 분리
• 각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를 반드시 포함
• 다음과 같은 특징을 지니도록 만든다
• 그림 22.1 클린 아키텍처

의존성 규칙

• 그림 22.1에서 각각의 동심원은 소프트웨어에서 서로 다른 영역을 표현

• 바깥쪽 원은 메커니즘이고, 안쪽 원은 정책

• 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙

  소스 코드 의존성은 반드시 안쪽으로 고수준의 정책을 향해야 한다
  

• 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다

• 외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다

• 우리는 외부 원에 위치한 어떤 것도 내부의 원에 영향을 주지 않기를 바란다

엔티티

• 엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다
• 엔티티는 메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합
• 전사적이지 않은 단순한 단일 애플리케이션을 작성하고 있다면 엔티티는 해당 애플리케이션의 업무 객체가 된다
• 이 경우는 가장 일반적이며 고수준인 규칙을 캡슐화
• 운영 관점에서 특정 애플리케이션에 무언가 변경이 필요하더라도 엔티티 계층에는 절대로 영향 X

유스케이스

• 유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함