함수형 아키텍처

함수형 프로그래밍?

수학적 함수(mathematical function)를 사용한 프로그래밍이다.

수학적 함수는 숨은 입출력이 없는 함수(또는 메서드)다. 

수학적 함수의 모든 입출력은 메서드 이름, 인수, 반환 타입으로 구성된 메서드 시그니처(method signature)에 명시해야 한다.

수학적 함수는 호출 횟수에 상관없이 주어진 입력에 대해 동일한 출력을 생성한다.

※ 사이드 이펙트: 메서드 시그니처에 표시되지 않은 출력(DB 저장, 예외 발생 등)

함수형 아키텍처?

어떤 사이드 이펙트도 일으키지 않는 애플리케이션을 만들 수는 없다.

함수형 프로그래밍의 목표는 사이드 이펙트를 완전히 제거하는 것이 아니라 비즈니스 로직을 처리하는 코드와 사이드 이펙트를 일으키는 코드를 분리하는 것이다. (결정을 내리는 코드 vs. 해당 결정에 따라 작용하는 코드)

함수형 아키텍처 vs. 육각형 아키텍처

공통점

• 결정(불변 코어, 도메인)과 실행(가변 셸, 애플리케이션 서비스)의 책임을 분리한다.
• 결정을 내리는 코드(불변 코어, 도메인)는 결정에 따라 작용하는 코드(가변 셸, 애플리케이션 서비스)에 의존하지 않는다.

차이점

• 사이드 이펙트에 대한 처리
  • 함수형 아키텍처: 모든 사이드 이펙트를 불변 코어에서 가변 셸로 밀어낸다.
  • 육각형 아키텍처: 도메인 계층에 제한하는 한, 도메인 계층으로 인한 사이드 이펙트는 수용한다. (도메인의 상태가 바뀔 수 있다!)

함수형 아키텍처의 단점

적용 가능성

비즈니스 로직 중간에 외부 의존성으로부터 추가 데이터를 질의해야될 수도 있다.
(e.g. 개발자는 연봉 인상률을 10%로 업데이트한다. 다만 근속년수가 3년 이상인 직원만 해당한다.)

이 경우 두 가지 해결책이 있다.

• 비즈니스 로직에 들어가기 전에 미리 필요할 지 모르는 내용을 수집한다.
• 비즈니스 로직에 해당 메서드를 만든 후, 애플리케이션 서비스에서 그 메서드를 먼저 호출하고 메인 메서드를 호출한다.

첫 번째 방법은 성능이 저하된다. 대신 비즈니스 로직에서 외부 의존성을 완전히 제거할 수 있다.

두 번째 방법은 분리가 완전이 안 된다. 대신 성능이 향상된다.

성능 저하

시스템 전체에 영향을 미치는 성능은 함수형 아키텍처의 흔한 논쟁이다. 외부 의존성을 더 많이 호출하기 때문이다.

'함수형 아키텍처 vs. 전통적 아키텍처'는 유지 보수성과 성능 간의 절충이다.

상황에 따라 잘 적용하자.

코드베이스 크기 증가

불변 코어와 가변 셸을 분리하면서 초기 코드량이 좀 많다.

모든 프로젝트, 모든 코드에서 함수형 방식을 따를 필요는 없다. 비용편익을 잘 따져서 적용하자.