의존성 제어

 

고수준 - 원의 안쪽, 추상화된 개념
저수준 - 원의 바깥쪽, 안쪽의 추상화된 개념을 어떻게 구현할지에 대한 개념

 

ex) 고수준이 ‘운동을 한다’라면, 저수준은 ‘집에서 팔벌려뛰기 운동을 한다’로 표현할 수 있습니다.

 

 

 

각각의 원들은 소프트웨어의 각기 다른 영역을 나타내고 있는데 바깥쪽의 레이어(저수준)를 메커니즘(Mechanism)이라 하고, 안쪽의 레이어(고수준)를 정책(Policy)이라고 한다.

• 안쪽 레이어 일수록 추상화가 높은 단계
• 안쪽 레이어는 바깥쪽 레이어에 관해 전혀 알지 못하며 따라서 바깥쪽 레이어에 선언된 어떠한 이름도 참조할 수 없다. (바깥쪽 레이어에 위치한 것은 내부 레이어에 영향을 주지 않게 해야 한다.)
  • 여기서 말하는 이름은 function, class, variable 등 이름이 붙은 모든 소프트웨어 엔티티들
• 데이터는 바깥쪽(Mechanism) 에서 안쪽(Policy)으로 이동 해야 한다.
• 모든 소스코드의 의존성은 반드시 바깥쪽(Mechanism) 에서 안쪽(Policy)으로 향해야 한다는 의존성 규칙

데이터 흐름

 

레이어	설명	예시
Entities	- 핵심 업무(비즈니스 규칙) 규칙을 캡슐화한다. - 메소드가 있는 객체이거나 데이터 구조 및 함수의 집합일 수 있다. - 가장 변하지 않고, 외부로부터 영향받지 않는 영역이다. - 특정 애플리케이션에 대한 운영 변경은 엔티티 계층에 영향을 주지 않아야 한다.	영화관에서 손님(클라이언트)은 '영화 예매'를 할 수도 있고, '예매 취소'를 할 수도 있고, '환불', '팝콘 사기'를 할 수도 있다. 이 때, 이런 '영화 예매', '예매 취소', '환불', '팝콘 사기' 등이, '영화관'이라는 시스템에 사용자가 요청할 수 있는, '영화관'의 Use case라고 한다. use case는 entities에 의존하는 동시에 상호작용한다. 앞서 말했듯 영화관에서 영화, 손님, 비용 등은 엔티티가 되고 손님이 영화를 예매하는 것은 유즈케이스가 된다.
UseCase	- 애플리케이션에 해당하는 비즈니스 규칙이 포함되어 있다. - 시스템의 모든 사용 사례를 캡슐화하고 구현한다. - 사용 사례는 엔터티와의 데이터 흐름을 조율한다. - 엔터티가 사용 사례의 목표 달성을 위해 전사적 비즈니스 규칙을 사용하도록 지시한다. - 변경해도 엔터티에 영향을 주지 않는다. - 데이터베이스, UI, 프레임 워크 등 외부 요소의 변경에 의해 영향을 받지 않는다.
Interface-Adators	- 일련의 어댑터들로 구성된다. - 어댑터는 데이터를 (유스 케이스와 엔티티에게 가장 편리한 형식) (데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식)으로 변환한다. - 컨트롤러, 프레젠터, 게이트웨이 등이 여기에 속한다. - 사용중인 지속성 프레임 워크에 가장 편리한 형식으로 변환됩니다.	번역기 역할 바깥 또는 안쪽으로 전달되는 모든 데이터를 데이터를 전달 받는 레이어에 용이한 형식으로 변환시켜주는 역할을 한다. 마찬가지로 이 계층에서 데이터는, 엔티티나 유스케이스에 용이한 형에서, 사용하고 있는 프레임워크에 용이한 형으로 변환된다. 예를들어 데이터베이스를 들 수 있다. 이 계층에 해당하는 원보다 안쪽에 존재하는 코드는 데이터베이스에 관해 아는 것이 없어야 한다. 만약 데이터베이스가 SQL 데이터베이스라면 어떤 SQL이든 이 계층에 제한돼야 하며 특히, 이 계층 내의 데이터베이스와 관련 있는 부분에 제한돼야 된다
Infrastructure	- 시스템의 핵심 업무와는 관련 없는 세부 사항이다. 언제든 갈아 끼울 수 있다. - 프레임워크나, 데이터베이스, 웹서버 등이 여기에 해당된다. 모든 세부 사항이있는 곳이다. 데이터베이스도 세부 사항	네트워크. HTTP, API, 웹 소켓, 소켓. 기본적으로 OSI 모델 또는 다른 대안은 단지 전달 메커니즘이에요. UI. Web UI, Native Window UI, Command Line, API, ViewController, Activity, Fragment. 이 것들은 모두 단지 UI 메커니즘이고 따라서 세부사항이죠. 데이터베이스. SQL, NoSQL, In-Memory, 파일 기반 데이터베이스. 데이터베이스는 단지 지속성 (persistence) 또는 캐싱 도구일 뿐이에요. 라이브러리와 프레임워크. 이 것의 예는 정말 많아요. 우리는 항상 라이브러리로 부터 어플리케이션의 코어 레이어를 추상화하려고 노력해야 해요. 그런데 몇몇 라이브러리는 크로스 커팅하기 때문에 이런 추상화가 언제나 가능하지는 않아요. I/O 장치. 입력 장치 (터치 스크린, 키보드), 지속성 장치 (NAND, HDD), 출력 장치 (스크린, 스피커). C로 작성된 리눅스 조차 입출력 장치를 위한 파일 추상화를 사용해서 커널을 정말 강력하고 이식성있게 만들어요.

 

언리얼 아키텍처

 

 올바른 의존성의 예시

• 호출하는 쪽이 호출 받는 쪽에 의존한다.
• 구상이 추상에 의존한다.
• 복잡한 것이 단순한 것에 의존한다.
• 알고리즘이 데이터 유형에 의존한다.
• 자주 변경되는 것이 별로 변경되지 않는 것에 의존한다.

 

 

클라이언트(사용자)가 상속 관계로 이루어진 모듈을 가져다 사용할때, 하위 모듈을 직접 인스턴스를 가져다 쓰지 말라는 뜻

하위 모듈의 구체적인 내용에 클라이언트가 의존하게 되어 하위 모듈에 변화가 있을 때마다 클라이언트나 상위 모듈의 코드를 자주 수정해야 되기 때문