05 아키텍처 (5)

21장. 소리치는 아키텍처

아키텍처의 테마

소프트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조

프레임워크는 아키텍처가 준수해야할 대상이 아닌, 아키텍처가 사용하는 도구

아키텍처의 목적

좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사(프레임워크, 데이터베이스, 웹 서버 등)에 대한 결합은 분리시킨다.

하지만 웹은?

웹은 전달메커니즘(입출력 장치)이며, 애플리케이션 아키텍처도 그와 같이 다뤄야 한다.

애플리케이션이 웹을 통해 전달된다는 사실은 세부사항이다.

프레임워크는 도구일 뿐, 삶의 방식이 아니다.

"프레임워크가 모든 것을 하게 하자"라는 태도는 잘못되었다.

프레임워크가 아키텍처의 중심을 차지하지 않도록 전략을 짜야한다.

테스트하기 쉬운 아키텍처

프레임워크나 웹서버, 데이터베이스 없이도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.

엔티티 객체는 간단한 객체여야 하고, 유스케이스 객체가 엔티티 객체를 조작해야 한다.

---

22장. 클린 아키텍처

아키텍처에 관한 여러 아이디어에서 공통적인 목표는 모두 '관심사의 분리'이다.

소프트웨어를 계층으로 분리함으로써 관심사의 분리를 달성할 수 있고, 다음과 같은 특징을 가진다.

• 프레임워크 독립성 - 프레임워크에 의존하지 않고, 도구로써 사용한다.
• 테스트 용이성 - 업무규칙은 UI, DB, 웹 서버 등 외부 요소 없이 테스트 할 수 있다.
• UI 독립성 - 시스템의 나머지 부분을 변경하지 않고도 쉽게 UI를 변경할 수 있다.
• 데이터베이스 독립성 - 업무규칙은 데이터베이스에 결합되지 않고, 타 DB로 자유롭게 교체할 수 있다.
• 모든 외부 에이전시에 대한 독립성 - 업무규칙은 외부 인터페이스에 대해 전혀 알지 못한다.

의존성 규칙

아키텍처가 동작하도록 하는 가장 중요한 규칙

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

외부 원의 요소가 내부 원에 영향을 주지 않게하기 위해, 내부 원에 속한 요소는 외부 원에 속한 어떤것도 알지 못해야한다. 

엔티티

전사적인 핵심 업무 규칙을 캡슐화

메서드를 가지는 객체이거나 일련의 데이터 구조와 함수의 집합도 가능

유스케이스

엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끔

유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함하며, 시스템의 모든 유스케이스를 캡슐화하고 구현

인터페이스 어댑터

데이터를 유스케이스와 엔티티에게 편리한 방식 -> DB나 웹 같은 외부 에이전시에게 편리한 방식으로 변환

프레임워크와 드라이버

세부사항에 해당하는 DB, 웹 프레임워크 등의 프레임워크나 도구들로 구성

경계 횡단하기

제어흐름과 의존성의 방향이 반대여야 할때에는 의존성 역전 원칙을 사용해서 해결한다.

동적 다형성을 이용해 소스 코드 의존성을 제어흐름과 반대로 만들 수 있고, 이를 통해 의존성 규칙을 준수할 수 있다.

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

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

엔티티 객체나 데이터베이스의 행이 전달되는 것은 데이터 구조가 의존성을 가지기 때문에 적절하지 않다.

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

전형적인 시나리오

데이터베이스를 사용하는 웹 기반 자바 시스템의 전형적인 시나리오

---

23장. 프레젠터와 험블 객체

험블 객체 패턴

테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다.

행위들을 두 개의 모듈 또는 클래스로 나눈다. 이 모듈 중 하나가 험블이다.

GUI 등의 테스트하기 어려운 행위를 모두 험블 객체로 옮기고, 테스트하기 쉬운 행위는 나머지 모듈로 옮긴다.

프레젠터와 뷰

뷰는 험블 객체이고 테스트하기 어렵다. 이 객체에 포함된 코드는 가능한 한 간단하게 유지한다. 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다.

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

테스트와 아키텍처

험블 객체 패턴에서 테스트하기 쉬운 패턴과 어려운 부분으로 경계가 정의되었듯이 테스트 용이성은 좋은 아키텍처가 지녀야 할 속성이다.

데이터베이스 게이트웨이

데이트베이스 게이트웨이는 다형성 인터페이스로, 애플리케이션이 데이터베이스에서 수행하는 생성, 조회, 갱신, 삭제 작업과 관련된 모든 메서드를 포함한다.

유스케이스 계층은 SQL을 허용하지 않으며, 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출한다.

인터페이스 구현체는 데이터베이스 계층에 위치하며, 이 구현체는 험블 객체이다.

데이터 매퍼

객체는 데이터 구조가 아니므로 객체 관계 매퍼(Object Relational Mapper, ORM) 같은건 사실 존재하지 않는다.

사용자는 private로 선언되는 데이터를 볼 수 없으며, public 메서드만 볼 수 있다. 따라서 사용자 관점에서 객체는 단순히 오퍼레이션의 집합이다.

객체와 달리 데이터 구조는 함축된 행위를 가지지 않는 public 데이터 변수의 집합이다.

ORM은 게이트웨이 인터페이스와 데이터베이스 사이의 일종의 또다른 험블 객체 경계를 형성한다.

서비스 리스너

애플리케이션은 데이터를 간단한 구조 형태로 로드한 후, 경계를 가로질러 특정 모듈로 전달한다.

그러면 모듈은 데이터를 적절한 포맷으로 만들어서 외부 서비스로 전송한다.

반대로 외부로부터 데이터를 수신하는 서비스의 경우, 서비스 리스너가 서비스 인터페이스로부터 데이터를 수신하고 간단한 구조로 변경하여 내부로 전달한다.