정책
소프트웨어 시스템이란 정책을 기술한 것
수준
입력과 출력까지의 거리
- 입,출력과 멀리 위치할수록 정책의 수준은 높아진다.
계속 같은 말이 반복된다. 중요하단 뜻이겠지
의존성은 저수준 컴포넌트에서 고수준 컴포넌트로 향해야 한다.
업무 규칙
사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차
엔티티
핵심 업무 규칙과 핵심 업무 데이터를 결합하여 만드는 객체
- 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것뿐이다.
유스케이스
자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무 규칙
- 자동화된 시스템이 사용되는 방법을 설명
- 엔티티 내부 핵심 업무 규칙을 어떻게 그리고 언제 호출할지를 명시하는 규칙을 담는다.
- 엔티티를 다루는 방법을 설명
- 사용자 인터페이스를 기술하지 않는다.
소리치는 아키텍처
건물의 청사진을 보고 어떤 건물인지 알 수 있는 것처럼 애플리케이션 아키텍처 역시 어떤 시스템인지 알 수 있어야 한다.
아키텍처 테마
소프트웨어 아키텍처는 유스케이스를 지원하는 구조
- 프레임워크로부터 아키텍처를 제공받아서는 안된다.
테스트하기 쉬운 아키텍처
- 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.
아키텍처를 통해 시스템이 보여야 한다는 것, 유스케이스를 중심으로 구조를 잡고 프레임워크에 구조를 의존하지 말것 모두 명심하자
결론 부분의 예시가 상당히 재미있다.
"모델처럼 보이는 것들을 확인했습니다. 그런데 뷰와 컨트롤러는 어디에 있죠?"
그러면 "그것은 세부사항이므로 당장은 고려할 필요가 없습니다. 나중에 결정할 겁니다." 이렇게 답할 수 있어야 한다는 게 흥미로웠다.
클린 아키텍처
시스템 아키텍처에 관한 여러가지 아이디어가 존재하지만 핵심적인 내용은 비슷하고 목표는 모두 같다.
관심사 분리
모든 아키텍처 아이디어가 공유하는 목표로 소프트웨어를 계층으로 분리함으로써 관심사 분리라는 목표를 달성하고 있다.
모든 아키텍처는 시스템이 다음과 같은 특징을 지니도록 만들어졌다.
프레임워크 독립성
프레임워크 존재 여부에 의존하지 않는다. 프레임워크를 도구로 사용한다.
테스트 용이성
업무 규칙은 UI, DB, 웹 서버 등 세부사항 없이도 테스트할 수 있다.
UI 독립성
시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다.
DB 독립성
DB를 교체할 수 있다.
모든 외부 에이전시에 대한 독립성
실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.
의존성 규칙
- 아키텍처가 동작하도록 하는 가장 중요한 규칙
- 소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.
엔티티
전사적인 핵심 업무 규칙을 캡슐화한다.
유스케이스
애플리케이션에 특화된 업무 규칙을 포함한다.
- 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끈다.
인터페이스 어댑터
- 어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 DB나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환한다.
모델을 재패키징하는 과정을 이야기하는듯 하다.
프레임워크와 드라이버
가장 바깥쪽 계층은 일반적으로 DB나 웹 프레임워크 같은 프레임워크나 도구들로 구성된다.
다시 또 같은말 고수준으로 향하게 하라
