Loosely-coupled 구현의 다양한 관점
도메인 스토리텔링 응용 12
<Loosely-coupled 그리고 스프링 프레임워크>편에서 Loosely-coupled 실현을 위해 쓰이는 패턴인 dependency injection을 소환해 설명했다. 하지만, 스프링 프레임워크를 떠올리면 자바 프로그램이나 인터페이스 활용으로 범주를 좁혀서 볼 수 있다. 클래스 레벨이나 자바에서만 가능할까? 그렇지 않다.
프로그래밍 방법 vs 프로그램 통합 시각
다시 loosely-coupled 정의를 보자.
in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.
마지막 줄에 보면 데이터(data)와 서비스(services)를 포함하고 있다. Loosely-coupled 페이지를 쭉 보면 In integration 이라는 영역과 In programming 이라는 영역이 있다. In programming은 <Loosely-coupled 그리고 스프링 프레임워크>편에서 다룬 내용과 관련이 깊다. 반면에 In integration 영역이 MSA와 관련이 깊다.
여기서 나는 그 상세 요소를 설명하지 않는다. 이 글의 목표는 맥락을 어떤 기준으로 나누는지 감각을 키우기 위해 loosely-coupled 라는 원칙 혹은 일종의 심미감을 개발하는데 도움을 주는 것이다.
BFF와 Loosely-coupled
이번에는 <Netflix API 아키텍처 진화>편에서 다룬 BFF 패턴을 소환하자. 아래 그림과 loosely-coupled 는 어떤 관련인가?
BFF 뒤쪽에서는 다양한 서비스 팜(농장처럼 풀어놓고 키우는 서비스)이 있다. '풀어놓고' 라는 비유는 일부러 선택했다. 세 개의 인터페이스 유형과 결합(tightly-coupled)을 없앤 것을 풀어놓아 키운다고 말할 수 있겠다. 그 역할을 BFF(Backend For Frontend)라고 규정한 구성요소(component)에 모아두는 것이다. 여기서 말한 구성요소는 하나의 계층으로 생각할 수도 있고, 작명 규칙을 부여한 특정 프로그래밍 단위로 정할 수도 있다. 이러한 일이 바로 여러분이 설계에 대한 감각을 키우는 일이다.
포트와 어댑터와 Loosely-coupled
<실용적인 포트와 어댑터 적용>편에 다룬 헥사고널 아키텍처를 소환해보자. 애플리케이션의 공통영역을 가운데 두고, 별도의 구성요소(레이어)에서 인터페이스하는 외부 요소의 유형에 따른 I/O 프로그램을 구분해서 Loosely-coupled 실현하라는 말이다.
그렇게 하지 않으면 특정 DBMS에 의존하는 프로그램이나 특정 UI 타입(GUI, http adapter 등), 또는 테스트 용도로 만든 코드 들이 공통의 응용프로그램에 모두 섞여서 프로그램 복잡도를 다루기 어려워지기 때문이다. 그래서, 지속적으로 성장하고 변할 프로그램이라면 이런 아키텍처를 참조해서 Loosely-coupled 실현하라는 말이다.
기능에 따라 층을 달리할 수 있는 사고법의 필요성
끝으로 최근에 발견한 Vaughn Vernon의 링크드인 메모로 마무리 한다.
Multi-layered 아키텍처 스타일이란 표현이 과거에 유행했다. 많은 개발자들이 이를 곡해해서 Controller-Model-View 정도로 이해했지만 2%만 이해한 것이라는 생각이 들었다.(10 여년전 이야기다.)
나는 20 년도 전에 포토샵을 공부할 때 layer를 나눠서 작업한 후에 병합(flatten)하는 절차가 너무나 아름답다고 느낀 바가 있다. 그래서 Multi-layered 하면 포토샵이 제공하는 View of Work(몰입을 유도하는 틀)가 자동으로 떠오른다.
위 그림을 세 번쯤 보고 저자의 의도를 이해했다. 그래서 떠올린 말이 Multi-layered 이고 포토샵의 아름다움이다. 사용자가 걷기를 원할 때는 보도라는 User Interface로 구현해야 한다. 반면에 수도나 전기를 흘릴 때는 굳이 보도에 구현하지 말고 땅속이나 공중을 이용한 매개체를 써야 한다. 이런 것들이 Multi-layered 구현이고 그걸 규칙화 하면 아키텍처라 할 수 있다.
어떤 면에서 BFF 나 포트와 어댑터 패턴은 이러한 원리의 사례일 뿐이고, 공학원리(혹은 건축 지식)로 말하면 Form Follows Function 이라는 지혜의 변종일 뿐이다.
지난 도메인 스토리텔링 응용
6. 도메인 모델, Ongoing 설계 그리고 정원관리
