Robert C. Martin의 Architecture

https://amara.org/ko/videos/0AtjY87egE3m/url/1216370/?tab=video

Robert C. Martin - Clean Architecture and Design | Amara

Summary

Rails 프레임워크로 애플리케이션을 작성하면 디렉토리 구조가 항상 동일하게 만들어진다.

프레임워크가 얼마나 중요하길래 최상위 디렉터리 구조를 결정지어 버리는 걸까?

 

The Web is a delivery mechanism! (I/O Channel)

웹 자체는 아키텍처적으로 중요하지 않다. 단지 데이터 전달 채널일 뿐이다.

웹 어플리케이션을 작성한다는 말은 이상하다. 그냥 어플리케이션이다.

8-90년대 웹이 급속도로 성장하고 번성했지만 근본적으로 변화된 건 아무것도 없다. 입출력 채널이 바꼈을 뿐..

 

건축 설계 도면을 보면 어떤 건물인지 금방 알 수 있다.

아키텍처는 의도를 표현하는 것이다.

Architecture is about INTENT!

Rails 애플리케이션의 디렉터리 구조는 의도를 표현하지 못한다. 단지 Rails 애플리케이션이라는 것만 알 수 있을 뿐..

 

이 문제는 1992년 이바 야콘슨이 저술한 Object-Oriented Software Engineering <A Use Case Driven Approach> 에서 이미 해결되었다.

유즈케이스에는 구현의 디테일이 나타나 있지 않다.

 

야콥슨이 말한 애플리케이션 아키텍처의 구성요소 3가지

Interactor: 유즈케이스의 입력, 출력, 처리 흐름을 구현한다. 애플리케이션 별(Application specific) 비즈니스 규칙을 가진다. 거기에는 모든 애플리케이션에 적용되는 글로벌 비즈니스 규칙과 개발중인 애플리케이션에만 적용되는 비즈니스 규칙이 있다. 유즈케이스는 애플리케이션에 따라 다르고 특정 애플리케이션에 종속된다. 입력 데이터를 생성해서 인터랙터를 호출하고 출력 데이터를 보는 방법으로 테스트한다.

Entity: 애플리케이션 비종속적인(Application independent) 비즈니스 규칙은 엔티티 오브젝트(비지니스 오브젝트)에 종속된다. 인터랙터가 엔티티 오브젝트들을 관장한다.

Boundary: 입력과 출력을 다른 유즈케이스에 전달한다. 이들은 OOP의 인터페이스로 정의되는데 인터랙터가 구현하는 인터페이스가 입력 인터페이스, 인터랙터가 사용하는 것은 출력 인터페이스이다. 그림에서 둘다 화살표가 인터랙터에서 나가는 방향!

사용자가 버튼이나 키보드를 통해 시스템에 데이터를 전달 -> RequestModel(POJO)로 변형 -> 입력 인터페이스를 통해 인터랙터에 전달 -> 인터랙터가 RequestModel을 해석 -> 작은 커맨드들로 변환하여 엔티티 메소드 호출 -> 작업이 끝나면 인터랙터가 엔티티의 변경사항 조회하여 ResultModel 생성(POJO) -> 출력 인터페이스를 통해 사용자에게 전달

 

MVC is NOT an Architecture

1970년대말~80년대초 트뤽비 린스카욱이 제시

이름을 가진 최초의 디자인 패턴

버튼, 텍스트필드, 체크박스 등 아주 작은 것들에 사용하는 목적으로 만들어짐

Model: 순수한 비즈니스 규칙을 담고 있고 입력값이 어디에서 오는지 모른다.(프로세스)

Controller: 입력 값 처리(사용자의 행동을 커맨드로 만들어 Model에 전달) (입력)

View: Model의 컨텐츠를 표시하거나 전달한다. Model의 변화를 옵저빙하고 있다가 화면을 업데이트한다. (출력)

 

MVC는 객체지향, 구조체, 객체, 애자일 등과 마찬가지로 오랜 시간동안 왜곡되었다.

오늘날의 많은 MVC 프레임워크들은 원래 MVC와는 전혀 다른 개념이다.

 

Presenter: 출력 인터페이스를 구현한다. Response Model(POJO)을 받아서 ViewModel(POJO)로 변형. Response Model을 입력한 후 결과로 나온 뷰모델을 체크하는 방식으로 테스트한다.

ViewModel: 출력 값을 표현하는 순수한 데이터 구조. 화면에 표시되는 모든 데이터와 상태 값을 저장한다. 프레젠터가 데이터를 화면에 보이는 형태로 변형하여 뷰모델에 추상화된 방식으로 저장한다.

View: 멍청하고 단순하게 뷰모델로부터 데이터를 가져가서 아무것도 처리하지 않고 그대로 표시한다. 일반적으로 테스트도 잘 안한다.

인터랙터는 입력 인터페이스로 들어온 Request Model에서 데이터를 읽는다.

Response Model에 데이터를 저장하고 출력 인터페이스를 통해 Presenter에게 전달한다.

검정색 선: 애플리케이션과 전달 메커니즘을 구분하는 선. 이 선을 지나는 모든 선이 애플리케이션을 향하고 있으므로 애플리케이션은 Controller나 Presenter에 대해서 아무것도 모른다.

I/O 메커니즘과 애플리케이션을 따로 패키징하는 게 바람직하다. I/O 메커니즘을 플러그인이라고 생각하라.

IDE 개발자와 플러그인 개발자 중에 상대방에 대해 아는 사람은 누구인가?

애플리케이션의 어떤 파트가 다른 파트로부터 보호되어야 할까? 

어떤 파트가 다른 파트의 변경에 따라 수정되어야 할까? 어떤 파트가 다른 파트의 변경에 영향을 받지 않아야 할까?

답은 명확하다.

비즈니스 규칙을 웹으로부터 보호해야 한다.

웹에 어떠한 변경이 생기더라도 비즈니스 규칙에는 영향이 없어야 한다.

아키텍처적으로 보장되어야 한다.

 

Database is a detail!

데이터베이스는 아키텍처 적으로 큰 의미가 없다.

데이터 저장소일 뿐이다.

비즈니스 규칙과도 아무런 연관이 없다.

이런 사소한 데이터베이스로부터 애플리케이션을 보호해야 한다. 그러면 데이터베이스를 플러그인처럼 언제든 교체할 수 있다.

Entity Gateway: 보통 하나의 엔티티에 게이트웨이 하나를 둔다. 모든 메소드가 쿼리 메소드.

Entity Gateway Implementation: 데이터베이스를 사용하는 Entity Gateway의 구현부. 애플리케이션 밖에 둔다.

 

오브젝트란 무엇인가? 퍼블릭 메소드들의 집합이다. 그 외에는 알려져선 안된다.

오브젝트는 데이터 덩어리가 아니라 메소드 덩어리다. 그러므로 오브젝트는 행위에 대한 내용 즉, 비즈니스 규칙에 대한 내용이다.

그럼 데이터스트럭처란 무엇인가? 누구에게나 공개되는 잘 알려진 데이터 요소들이다. 메소드가 없다.

 

프레임워크는 많은 시간을 절감해주지만 프레임워크 제작자들은 우리를 프레임워크에 종속되도록 유도한다.

프레임워크의 베이스 클래스를 상속하는 순간 아주 강하게 커플링된다.

상속보다 더 강한 관계는 없다. 다른 사람의 베이스 클래스를 상속한다는 것은 아주 무거운 맹세를 하는 것과 같다.

반대로 프레임워크는 우리에게 아무런 책임도 지지 않는다.

현명한 아키텍트는 프레임워크를 비판적으로 바라보고 절대로 이런 비대칭적인 관계를 맺지 않는다.

 

A good architecture allows major decisions to be Deffered!

좋은 아키텍처는 중요한 의사결정을 뒤로 미룰 수 있게 한다.

아키텍처의 목표는 결정을 안하는 것이다.

가능한 한 정보를 많이 가지고 결정할 수 있게 미루고 미루는 것이다.

상위 레벨의 결정을 미룰 수 있도록 설계해야 한다.

애플리케이션 아키텍처를 설명할 때 프레임워크 이름을 말하지 말라. 프레임워크는 툴일 뿐이다.

애플리케이션의 아키텍처는 유즈케이스들이다. 유즈케이스는 툴에 대해 몰라야 한다.

툴에 대한 결정을 최대한 늦게 해야 한다.

웹이나 데이터베이스 없이 애플리케이션의 모든 부분을 실행할 수 있어야 한다.

A good architecture maximize the number of decisions NOT made.

 

Plugin model

GUI, 데이터베이스, 프레임워크 같은 디테일들은 모두 유즈케이스의 플러그인이 되어야 한다.

유즈케이스가 애플리케이션의 핵심이다.