지난 수업 시간에 functional programming을 가르치기 위해 학습하면서 나름 functional programming이 재미있다는 생각을 하고 본격적으로 공부해볼 생각이다. 그런 마음으로 인사이트에서 출간한 "프로그래밍 클로저"를 읽고 있다. 이제 2장까지 밖에 읽지 못했지만 이 책을 읽으면서 이런 엉뚱한 생각을 해봤다. 가능할지의 여부는 아직 모르겠다. 이후에 클로저를 활용한 프로그래밍에 자신이 있으면 한번 시도해 봐야겠다.

엉뚱한 생각은 다음과 같다.

자바 기반으로 웹 애플리케이션을 개발할 때 다음과 같은 구조로 개발하는 경우가 대부분이다.

Controller + Service + Repository(Dao)에 핵심 비지니스 로직을 담고 있는 도메인(domain) 영역이 있을 것이다. 물론 객체 지향적으로 개발한다고 가정했을 때의 이야기이다. domain(흔히 model 클래스라고도 이야기한다.) 클래스의 경우 DTO(data transfer object)의 역할을 담당하는 경우도 일반적이다.

위 구조를 클로저를 활용한다면 다음과 같이 구현할 수 있지 않을까?

Controller + Service + Repository(Dao)와 같은 Layered Architecture 구조는 동일하다. 달라지는 부분은 핵심 비지니스 로직을 담당하는 도메인 영역이다. 비지니스 로직은 자바로 구현하는 것이 아니라 클로저로 구현하면 어떨까? 그리고 기존에 도메인 클래스가 중복된 개념으로 가지고 있었던 DTO는 별도의 자바 클래스로 분리하고... 즉, DTO는 setter와 getter, ORM을 사용하는 경우 테이블과의 매핑을 담당하는 역할을 하고 핵심 비지니스 로직은 모두 클로저로 구현할 수 있지 않을까?

이 같은 구조로 가자고 하면 복잡도 증가한다면서 반대할 사람들 많을 듯하다. 일단 가능할지의 여부도 아직 모르겠고, 클로저 책 하루 보고 자바 클래스와의 연동이 쉽다고 하니 이런 구조면 좋지 않을까라는 생각을 해봤다. 최근에 학생들을 보면서 객체가 상태를 유지하고, 상태를 변경해 가면서 문제를 풀어가는 것이 생각보다 어렵겠다는 생각을 했다. 그런 관점에서 functional programming을 활용한다면 객체 지향 언어보다는 좀 더 쉽게 접근할 수 있지 않을까라는 생각을 한다. 어차피 복잡하고 중요한 부분은 도메인 영역에 대부분 존재하고 나머지 요소들은 부가적인 기능을 지원하는 구조이기 때문에 복잡도가 증가하는 경우 괜찮지 않을까? 두 가지 이상의 언어를 학습해야 하는 부담만 증가하는 건가? 걸어서 출근하면서 생각해본 엉뚱한 생각이었다.