18장 경계 혜부학

시스템 아키텍처는 소프트웨어 컴포넌트와 그 컴포넌트들을 나누는 경계로 이루어져 있음

경계를 횡단한다는 말은 경계를 넘어 함수를 호출해 데이터를 전달하는 일

경계를 잘 구분해서 의존성 관리를 하면 불필요한 재컴파일, 재배포를 막을 수 있음

아키텍처 경계 중 가장 흔한 형태로 소스 수준의 분리 모드라고 부른다.

물리적으로 분리되어 있지 않기 때문에 배포 관점에서는 경계가 드러나지 않음.

이런 경계 수준에서는 동적 다형성을 이용해서 의존성을 관리한다.

저수준에서 고수준으로 향하는 함수 호출은 제어 흐름과 의존성의 방향이 같아서 의존성 방향이 저수준 → 고수준이기 때문에 상관없지만

고수준에서 저수준으로 향하는 함수 호출은 의존성의 방향이 고수준→저수준으로 향하기 때문에 동적 다형성을 이용해서 역전시켜 주어야 함

이렇게 의존성을 관리하면 고수준의 컴포넌트를 저수준 세부 사항으로부터 보호할 수 있고 독립적인 개발, 테스트, 배포가 가능함

단일체와 비슷하지만, 컴포넌트를 배포할 수 있는 형태로 분리해낸 형태로 배포 수준의 분리 모드라고 한다.

사용할 때 필요한 기능을 참조하여 호출하는 동적 링크 라이브러리로서 경계가 물리적으로 드러남

19장 정책과 수준

소프트웨어 시스템은 정책의 기술이다.

정책이라는 말이 모호하게 들리겠지만 각 입력을 어떻게 출력으로 변환할지 기술하는 것에 불과하다. 하나의 정책은 작은 정책들로 쪼개질 수 있음

정책이 변경되는 양상에 따라서 컴포넌트로 분리해야 함

아키텍처 개발은 이렇게 분리한 컴포넌트 간의 의존성을 정의하는 것. 고수준 컴포넌트로 의존성 방향이 향하도록.

수준(level)이란 정책이 입력과 출력으로부터 얼마나 떨어져 있는지의 거리. 거리가 멀수록 고수준이다.

정책을 컴포넌트로 묶는 기준은 정책이 변경되는 시점과 이유다.

고수준의 정책은 저수준의 정책보다 덜 빈번하게 변경되어야 한다.

업무 규칙이란 애플리케이션 외부에 실재하는 사업적인 규칙 또는 절차.

이러한 절차를 핵심 업무 규칙이라고 한다. 그리고 이 규칙에 요구되는 데이터는 핵심 업무 데이터라고 한다.

핵심 업무 규칙과 데이터로 이루어진 객체를 엔티티라고 한다.

핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙.

유스케이스는 애플리케이션에 특화된 자동화된 업무 규칙이다.

유스케이스는 업무 규칙을 이용해서 사용자와 엔티티가 어떻게 상호작용할지 제어한다.

유스케이스는 상대적으로 고수준인 엔티티에 의존한다.

업무 규칙은 시스템이 존재하는 이유라고 할 만큼 핵심적인 것. 저수준의 다른 것들로부터 오염되지 않도록 보호해야 한다.

아키텍처란 건물 설계도와 같다

건물 설계도를 보면 이 건물이 어떤 용도인지 한눈에 알 수 있음

예를 들면 책장 진열하는 공간, 바코드 찍는 공간, 책 반납하는 공간, 책을 읽는 공간을 보면 한눈에 도서관임을 알 수 있음

앱도 마찬가지로 앱 아키텍처는 건물 설계도처럼 사용 사례를 중심으로 만들어져야 함

사용 사례를 중심으로 고려하면 DB, API 등 부차적인 것들은 쉽게 바꿀 수 있음

프레임워크는 뒷순위임. 건물 지을 때 벽돌, 시멘트, 나무 등의 재료는 나중에 고려하는 것처럼

프레임워크는 도구일 뿐이기 때문에 종속되지 않도록 주의해야 함

잘 짜인 아키텍처는 테스트가 용이함

서버를 돌릴 필요도, db 연결도, 프레임워크도 필요 없기 때문에

결론, 내가 헬스케어 앱을 만들었다면 후임자가 소스 코드를 봤을 때 헬스케어 앱이구나 하고 첫눈에 알아차릴 수 있어야함.

핵심 모델(use case)이 먼저 보여야 하고 View나 Controller는 나중에 보일 것임