05 아키텍처 - 4

22장 클린 아키텍처

 

관심사 분리- 소프트웨어를 계층으로 분리.

- 최소한 업무규칙을 위한 계층, 사용자와 시스템 인터페이스를 위한 다른계층 하나 포함.

 

• 프레임워크 독립성
• 테스트 용이성.
• UI 독립성
• 데이터베이스 독립성.
• 모든 외부 에이전시 에 대한 독립성

 

 

의존성 규칙

보통 안으로 들어갈수록 고수준의 소프트웨어.

바깥쪽 - 메커니즘, 안쪽  -정책

 

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

외부원에 위치한 것은 내부 원에 영향을 주지 않게 해야한다.

 

엔티티

엔티티는 핵심업무 고수준인 규칙을 캡슐화 함.

해당 애플리케이션의 업무 객체.

 

유스케이스

유스케이스 계층은 애플리케이션 특화 업무규칙을 포함.

엔티티로 들어오고 나가는 데이터 흐름을 조정. 

이 계층에서 발생한 변경이 엔티티에 영향을 주면 안됨.

 

인터페이스 어댑터

어댑터들로 구성.

GUI의 MVC 아키텍처 포괄.

데이터를 엔티티와 유스케이스에게 편리한 형식에서 프레임워크가 이용하기 편리한 형식으로 변환.

외부적 형식에서 유스케이스나 엔티티가 사용되는 내부적 형식으로 변환.

 

프레임워크와 드라이버

모든 세부사항이 위치하느 곳.

웹, 데이터베이스 등의 세부사항.

 

원은 네개여야만 하나?

원의 갯수는 더 많을수도 있음. 하지만 의존성규칙은 항상 적용됨.

소스코드 의존성은 안쪽으로.

안쪽으로 갈수록 추상화와 정책의 수준은 높아짐.

 

경계 횡단하기

그림의 우측 하단의 경계 횡단 방법.

제어흐름과 의존성 방향이 반대여야 하는경우 의존성 역전 원칙을 사용해 해결.

유스케이스가 내부 원의 인터페이스를 호출하게 하고, 외부 원의 프레젠터가 그 인터페이스를 구현하도록 만듬.

 

경계를 횡단하는 데이터는 어떤 모습인가

격리되어 있는 간단한 데이터 구조가 경계를 가로질러 전달.

쿼리에 행 구조가 경계를 넘어 내부로 그대로 전달되는 것은 의존성 규칙에 위배됨.

데이터는 항상 내부 원에서 사용하기 편리한 형태를 가져야 함.

 

전형적인 시나리오

웹기반 자바시스템의 전형적 시나리오

모든 의존성은 경계선 안쪽으로. 의존성 규칙 준수.

 

결론

.소프트웨어를 계층으로 분리하고 의존성 규칙을 준수하면 테스트하기 쉬운 시스템을 만들게 됨.

 

---

23 프레젠터와 험블객체

 

 

험블 객체 패턴

디자인 패턴, 테스트하기 어려운 행위와 쉬운행위를 단위테스트 작성자가 분리하기 쉽게 하는 방법으로 고안.

행위들을 두개의 모듈로 나누는데 테스트하기 어려운 행위를 모두 험블 객체인 하나의 모듈로 옮김.

다른 모듈에 테스트하기 쉬운 행위를 옮김.

 

프레젠터와 뷰

뷰는 데이터를 GUI로 이동시키지만 데이터를 직접 처리하지 않음. 험블객체, 테스트하기 어려움.

프레젠터는 애플리케이션에서 데이터를 받아 화면에 표현할 수 있는 포맷으로 만듬. 테스트하기 쉬운 객체

 

프레젠터가 적절한 형식의 문자열이 테이블 형태를 가지도록 뷰 모델에 로드.

뷰는 뷰 모델의 데이터를 화면으로 로드할 뿐 보잘것 없다 humble

 

테스트와 아키텍처

행위를 테스트하기 쉬운부분과 어려운부분으로 분리하면 아키텍처 경계가 정의됨.

 

데이터베이스 게이트웨이

유스테이스 인터랙터와 데이터베이스 사이에 위치함.

다형적 인터페이스로 디비에서 수행하는 모든 메서드 포함함.

 

유스케이스 계층은 필요한 메서드를 제공하느 게이트웨이 인터페이스를 호출,

데이터베이스 계층에 인터페이스 구현체 - 험블객체가 위치한다.

구현체에서 직접 sql 사용, 게이트웨이의 메서드에 필요한 데이터에 접근.

 

게이트웨이는 스텁으로 적당히 교체할 수 있기에 험블객체가 아님.

 

데이터 매퍼

객체 관계 매퍼 ORM 은 사진 존재하지 않음.

객체는 데이터 구조가 아니기 때문, 데이터는 모두 private 으로 선언되므로 사용자는 public 메서드만 볼 수있음.

객체는 단순 오퍼레이션의 집합.

 

데이터 구조는 행위를 가지지 않는 public 데이터 변수의 집함.

ORM 보다 데이터 매퍼 라 하자.

 

ORM은 데이터베이스 계층에 위치.

게이트웨이 인터페이스와 데이터베이스 사이에서 또다른 험블 객체 경계를 형성.

 

서비스 리스너

서비스 경게를 생성하는 험블객체 패턴 존재.

데이터 구조 로드->경계를 가로질러 특정 모듈로 전달->적절한 포맷으로 만들어 외부로 전송.

외부로부터 데이터 수신->애플리케이션에 사용할 구조로 포맷변경->경계를 가로질러 내부로 전달.

 

결론

경계마다 숨어있는 험블객체 패턴이 있다.

이는 시스템 테스트 용이성을 높인다.

---

24장 부분적 경계 Partial boundary

아키텍처 경게를 만드는데 모든 의존성 관리와 많은 노력이드는데,

나중을 위한 설계에 너무 많은 비용을 들인다고 생각한다면,

부분적 경계로 구현할 수 있음.

 

마지막 단계 건너뛰기

쌍방향 인터페이스, 입출력 데이터 구조를 포함 하는 모든것을 만들고 단일컴포넌트로 컴파일해서 배포하는 방식.

다수의 컴포넌트를 관리하는 작업을 하지않는 것.

 

일차원 경계

추후 확장을 확보하고자 할때 활용할 수 있는 간단한 구조, 전통적 Strategy 패턴 사용.

미래에 필요한 아키텍처 경계를 위한 무대. Client를 ServiceImpl 로부터 격리시키는데 필요한 의존성 역전 적용.

 

퍼사드

단순한 경계는 퍼사드 패턴으로.

경계는 Facade 클래스로만 정의. 모든 서비스 클래스를 매서드 형태로 정의. 

서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달.

 

클라이언트는 서비스 클래스에 직접 접근 할 수 없음.

클라이언트가 모든 서비스 클래스에 대해 추이 종속성을 가짐.

 

결론

아키텍처 경계를 부분적으로 구현하는 간단한 방법 세가지.

각 접근법은 적절하게 사용할 상황이 다르며, 해당 경계가 실제로 구체화되지 않으면 가치가 떨어짐.

아키텍처가 경계가 언제, 어디에 둘지, 경계를 완벽하게 또는 부분적으로 구현할지 결정해야 함.