Spring Service 설계와 Transaction 처리

과거에 DB Transaction 은 그냥 알아서 잘해...라는 방식이었다....조금 진보되어 Framework 개념이 나오고 공통모듈 개념이 나오면서 Connection leak 을 막기 위해서 공통개발자가 Abstract 로 구현하던지 유틸을 구현하던지 해서 처리하는 방식...

Spring 에서 선언적/명시적 Tx 를 지원하면서 현재는 Tx를 수동(?) 으로 처리하지 않고 Spring 이 자동으로 Service Layer의 지정된 method 단위로 처리하게끔 한다.

문제는 여기서 발생.......MVC 에서 Service Layer를 설계 할때 method 의 기준이 애매해 진다...

비즈니스에서 얘기하는 서비스의 기준과 DB 에서 Tx 단위로 사용될 Method 의 기준이 Service Layer에 혼재되면서 Tx의 기준이 모호해 진다. 특히 타 시스템과의 인터페이스를 웹으로 주고 받으면서 통신해야 되는 업무는 더더욱 애매해 진다...

가장 흔한 예로 상품 구입후 결제하는 경우를 보면...

사용자는 결제버튼 클릭하면 결제OK 나오는게 하나의 서비스이고 이것이 비즈니스의 단위 Tx 이다. 그러면 Service Layer 에 하나의 Method 에 결제라는 함수를 만들었다고 해보자....

이 함수는 오만 잡동사니 웹 인터페이스들과 DB Tx 특히, 두개 이상의 이원화된 DB 가 있는경우 다량의 Tx 가 하나의 Service Method 로 구현된다.....이 코드는 적어도 수백 많으면 수천 라인이상의 코드가 될 것이다....실제로 이런 사이트들이 상당수 존재한다...

그럼 어쩌라구.....?

Spring 의 선언적 Tx 를 사용하기로 했다면 그때 부터 그 선언적 범위내에 포함되는 Service Method 들은 DB Tx을 기준으로 구성되어야 한다. 그래야 코드가 간단해지고 재사용성도 올라간다. 

또한, 각종 웹을 이용한 인터페이스들도 별도의 Service Method 들로 구성해야 한다. 물론 웹은 일반적으로 Tx를 지원하지 않으므로 선언적인 Tx의 범위에서 제외해야 한다.

그러면 사용자의 비즈니스 서비스들은? 

별도의 Layer 에 구성해야 한다. BizService 라고 이름지어도 좋고, Process 라는 Layer 를 별도로 구성해도 괜찮다. 작은 사이트의 경우 Controller 에 통합해도 무방하다.

이렇게 하므로써 DB Tx Service Method 들과 웹 Service Method 들을 조합하여 비즈니스서비스들을 비즈니스 흐름대로 구성하고 필요시 재조합해서 신규 비즈니스서비스들을 유연하게 구성할 수 있게 된다.

그래서 일반적인 흐름은 Controller <-> BizService(or Process) <-> (DB Service, Web Service, EDI, ESB, EAI 등 각종 이질적인 서비스들의 조합) 이러한 형태가 되는게 Spring의 선언적 Tx 의 장점도 살리면서 비즈니스서비스코드의 유지보수성도 높이는 방안이다.

경우에 따라서 각종 인터페이스들이 많고 모니터링 해야 하는 경우 BizService Layer 와 엮어서 모니터링 툴을 사용하던지, ESB 미들웨어를 도입해서 Biz Flow Service 들을 웹서비스로 가변화 시키던지 해도 된다.

* 2016.12.27 추가

Domain-Driven Design(DDD , 에릭에반스) 에 의하면 저자는 서비스를 Application, Domain, Infrastructure 세가지로 나누었다...

1. Application Service : 암호화, 엑셀다운, 파일첨부 등...비즈니스 업무와 관련 없는 서비스들, 아마 프로젝트에서는 오픈소스 라이브러리나 상용소프트웨어를 사용해서 개발/설계하는 경우가 될 것이다...

2. Infrastructure Service : 이메일발송, 배치작업, 로그생성, 모니터링 등...주로 하드웨어 인프라와 관련된 서비스들인데 주로 미들웨어에서 처리해 주는 기능들이 될 것이다..

3. Domain Service : 실제 비즈니스 규칙들이 적용되서 개발/설계되는 서비스들 이다. 예약/이체/결제 등등....

위의 세가지 서비스들과 DB Tx를 비교하자면 DB Tx는 주로 Domain Service 와 1:1 로 매칭될 것이고 Process Layer 는 Application, Infrastructure 들이 Domain Service 와 결합된 형태로 도출 될 것 같다...