본문 바로가기

IT Book Summary/Clean Architecture

05 아키텍처 - 3

19장 정책과 수준

 

소프트 웨어 시스템 - 정책을 기술한 것.

 

아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함.

 

의존성은 소스코드, 컴파일타임의 의존성.

자바의 경우 import, C#에서는 using 구문, 루비에서는 require 구문.

각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 함.

저수준 컴포넌트가 고주순 컴포넌트에 의존하도록 설계

 

수준 level

: 입력과 출력까지의 거리

 

입력과 출력을 다루는 정책이라면 시스템 최하위 수준에 위치하게 함.

 

암호화 프로그램

소스코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되서서는 안됨.

 

function encrypt() {
  while(true)
  writeChar(translate(readChar()));
}

고수준인 encrypt 함수가 저수준인 readChar와 writeChart 함수에 의존하기 때문에 잘못된 아키텍처.

더 나은 아키텍처

고수준의 암호화 정채을 저수준의 입출력 정책으로부터 분리시킨 방식.

입출력 변경으로부터 암호화 정책이 영향받지 않음.

소스코드 의존성 방향이 고수준 정책을 향함.

 

저수준 컴포넌트가 고수준 컴포넌트에 플러그인

결론

정책에 대한 논의는

단일 책임 원칙, 개방 폐쇄 원칙, 공통 폐쇄 원칙, 의존성 역전 원칙, 안정된 의존성 원칙, 안정된 추상화 원칙을 모두 포함.

 


20장 업무 규칙 Business Rules

애플리케이션을 업무규칙과 플러그인으로 구분.

 

컴퓨터상으로 구현했는지와 상관없이, 업무규칙은 사업적 수입, 비용을 줄일 수 있는것.

핵심 업무 데이터 Critical Business Data

핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있어 객체로 만듬 - 엔티티 

엔티티 Entity

:  핵심 업무 데이터를 기반으로 동작하는 일련의 핵심 업무규칙을 구체화.

핵심 업무 데이서 + 핵심 업무 규칙을 구현한 함수.

 

Loan 엔티티 UML 클래스

업무의 대표자로 독립적으로 존재. 

핵심업무 데이터와 업무 규칙을 하나로 묶어 별도의 소프트웨서 모듈로 만듬.

유스케이스 use case

유스케이스는 자동화된 시스템이 사용되는 방법, 애플리케이션에 특화된 업무규칙을 설명.

엔티티 내부의 핵심 업무규칙을 어떻게 , 언제 호출할지를 명시하는 규칙을 담음.

사용자 인터페이스를 기술하지는 않음. 시스템에서 데이터가 들어오고 나가는 방식은 무관함.

 

유스케이스 예제

객체로서, 애플리케이션에 특화된 업무규칙을 구현하는 하나 이상의 함수를 제공.

입출력 데이터, 상호작용하는 엔티티에 대한 참조데이터 등 요소를 포함.

 

엔티티는 고수준, 유스케이스에 의존하지 않음.

유스케이스는 저수준. 단일 애플리케이션에 특화되어 있고, 엔티티에 의존함.

 

요청 및 응답 모델

유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 

단순한 응답데이터 구조를 출력으로 반환.

이들 데이터 구조는 어떤것에도 의존하지 않음.

 

결론

업무규칙은 핵심적인 기능.

시스템에서 독립적이며 많이 재사용할 수 있는 코드여야 함.

덜 중요한 코드는 플러그인.

 


21장 소리치는 아키텍처 

 

아키텍처의 테마

소프트웨어  애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 함.

아키텍처는 프레임워크에 대한것이 아님. 도구일 뿐.

 

아키텍처의 목적

좋은 아키텍처는 유스케이스를 중심에 둠.

프레임워크는 열어둬야할 선택사항.

 

하지만 웹은?

웹은 전달 메커니즘(입출력 장치)

근본적인 아키텍처를 고치지 않고 시스템을 콘솔 앱, 웹 앱, 웹서비스 앱 으로도 가능해야 함.

 

프레임워크는 도구일 뿐, 삷의 방식은 아니다

아키텍처를 유스케이스에 중점을 둔 채 그대로 보존할 수 있을지 생각하자.

프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하자.

 

테스트하기 쉬운 아키텍처

필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 함.

웹 서버, 데이터베이스 연결은 불필요 함.

엔티티 객체는 간단한 객체 plain old object 여야 하며, 다른 프레임워크나 디비에 의존하지 않아야 함.

그러면서 그대로 테스트 가능해야 함.

 

결론

아키텍처는 프레임워크가 아닌 시스템을 이야기 해야함.

처음 보는 사람이 소스코드를 보아도 시스템의 유스케이스를 이해할수 있게 해야 한다.

 

 

 

 

 

 

'IT Book Summary > Clean Architecture' 카테고리의 다른 글

05 아키텍처 - 5  (0) 2021.03.28
05 아키텍처 - 4  (0) 2021.03.20
05 아키텍처 - 2  (0) 2021.03.08
05 아키텍처 - 1  (0) 2021.03.01
04 컴포넌트 원칙 -2  (0) 2021.03.01