Web service architecture 에 관하여.

Web Service Architecture 에 관하여 고민한 결과

이 글은 페이스북 한국 스프링 사용자 모임에 올렸던 package 설계에 관한 고민에서 시작되었습니다.

1. package 구조 type1/2에 대해서 프로젝트 상황에 따른 선호도가 있다고 들었습니다.

작은 프로젝트인 경우에는 type2, 각각의 기능이 커서 따로 관리가 필요한 경우에는 type1을 선호한다고 들었습니다.

개인적으로는 아무리 작은 프로젝트라도 이후에 재사용성을 고려한다면 type1으로 진행하는 것이 좋지 않을까요? 

저 같은 경우에도 type2로 진행하는 경우가 많이 있었는데, 솔직히 이미 틀이 잡혀 있었기 때문에 수정 불가(현실적으로)었거나 큰 고민없이 관성적으로 한 경우가 있었습니다.

또한 개발자에 따라서는 너무 많은 package로 인한 관리의 어려움 때문에 type2를 선호하는 경우도 있었습니다.

type1/2에 관한 정답이 있을까요?

2. 로버트 C 마틴. 아저씨가 제시한 package 설계원칙들과 함께 고민하다보니 서로의 의존성 때문에 고입이 됩니다.

type1이든 type2든 응집력과 연관성의 규칙을 지키려다 보면 각기 다른 package에 있는 클래스를 사용해야 할 때 어떻게 해야 할까요? 예를 들어 UserController에서 BoardService/BoardDao를 사용해야 한다면요? BoardService에서 User 도메인과 조인을 해야 하는 경우에는요?

..

많은 분들이 관심을 가져 주셨고, 많은 의견들을 주셨습니다.

제 고민의 결과는 type2처럼 Controller와 Service, Dao를 분리하는 것이 더 좋은 architecture 입니다.

웹 서비스의 layer는 presentation, application, database 영역으로 크게 구분 될 수 있을 것 입니다.

그중에 Controller는 presantation 영역에 가깝고(같다는 의미가 아닙니다.) Service 는 application 영역에 가깝습니다. 그리고 Dao는 Database 영역에 가깝지요.

이식이 가능한 mobilable 어플리케이션을 만들려면 presantation layer와 application layer, database layer가 완전히 분리 되어야 합니다.

그리고 의존성은 가장 중요한 application 영역을 향해야 합니다.

 

초보 시절 많이 하던 실수는 Controller의 Http 객체를 Service layer에 파라미터로 전달하는 것이었습니다.

requset, mode, session 등을 service layer에 던져서 parameter를 뽑거나 model에 addAttribute등을 하였습니다.(저의 죄를 용서하여 주시옵소서).

이 것이 무엇이 문제냐면 Application이 Presentation에 의존을 하게 되는 것 입니다.

이렇게 되면 문제점은 Application Layer를 다른 곳으로 이동 시킬 수가 없습니다. 만약 Http를 사용하지 않는 PC프로그램으로 application을 옮겨야 한다면 재사용 할 수가 없습니다.

이제부터라도 layer를 완벽하게 분리해야 할 것 같습니다.

이를테면 웹 서비스를 하고 있는데, 모바일 네이티브 앱도 서비스를 하게 된다면 어떻게 해야 할까요?

1안)

application단만 가지고 새롭게 만들수도 있겠지요. 

2안)

Controller단도 그대로 같이 쓸수도 있습니다. 

MVC 패턴을 잘 지킨 웹 서비스라면 2안으로도 가능할 것 같습니다.

만약 아래와 같은 그림으로 layer가 나뉘어 있다면요.

View Request에서는 순수 html(jsp) 파일만 받아오고 데이터는 Rest API를 통해서 받아와야 합니다. 한 request안에서 response할 때 html과 데이터를 같이 넘기면서 서버단에서 화면을 만들어서 올리면 안된다는 뜻 입니다.

사용자가 늘어날 경우 서버단에서 해야 할 연산을 사용자에게 넘기는 결과를 주기 때문에 적은 서버 하드웨어 리소스로 더 많은 사용자를 감당할 수 있습니다.

Controller에서 View page에 관한 요청과 데이터에 대한 요청을 완벽하게 구분시킨다면 모바일 네이티브 앱에서는 아래 그림과 같아 집니다.

당연히 추가적인 작업은 필요하겠지만 기존 코드를 최대한 활용할 수 있습니다.

요 며칠 많이 고민이 되었었는데, 개인적으로나마 정리를 할 수 있게 되어서 다행입니다.