Spring Application Architecture

스프링 공부를 하면서 가장 자주 사용되며 단순한 그렇지만 중요한 구조에 대해 알아보려 한다.

그냥 내가 공부하고 코드를 작성할 때 유의하며 작성하면 더 좋은 구조가 될 것 같아 스스로 학습하기 위해 작성한다.

 

728x90

반응형

SMALL

 

가장 단순한 구조는 역할에 따라 3가지 계층으로 나누는 것이다.

 

프레젠테이션 계층

• UI 관련 처리 담당
• 웹 요청과 응답
• 사용자 요청을 검증
• 주 사용 기술: 서블릿과 HTTP같은 웹 기술, 스프링 MVC

서비스 계층

• 비즈니스 로직을 담당
• 주 사용 기술: 가급적 특정 기술에 의존하지 않고, 순수 자바 코드로 작성

데이터 접근 계층

• 실제 데이터베이스에 접근하는 코드
• 주 사용 기술: JDBC, JPA, Redis, Mongo,...

 

순수한 서비스 계층이란?

서비스 계층은 가급적 특정 기술을 의존하지 말아야 한다는 말은 어떤 의미일까?

시간이 흘러 웹(UI)과 관련된 기술이 변하고, 데이터 저장 기술을 다른 기술로 변경할 여지는 충분하다. 지금 사용하는 기술보다 더 좋은 기술이 탄생한다던가, 지금 사용하고 있는 기술이 요구사항을 만족할 수 없는 기술이라면 사용하다가도 변경해야 한다.

그러나, 그렇다 한들 비즈니스 로직은 사용하는 기술이 바뀐다고 변경하지 않는다. 서비스가 다루는 기능이 변하거나 새로운 기능이 추가, 변경되어야 하는 경우가 아니면 비즈니스 요구사항이 변경될 리 없고 그 요구사항을 다루는 로직도 기술에 의존해서 변경되면 안 된다. (물론 이상적인 경우일 때를 말한다)

 

그렇기 때문에 서비스 계층은 가급적 특정 기술에 의존하면 안 된다는 뜻이다. 그래서 서비스 계층에 대해 코드를 작성할 때도 이 점을 유의하면서 작성해야 한다. 예를 들어, 프레젠테이션 계층은 클라이언트가 접근하는 UI와 관련된 기술인 웹, 서블릿, HTTP와 관련된 부분을 담당해 준다. 그래서 서비스 계층을 이런 UI와 관련된 기술로부터 보호해 준다. 그 결과로, REST API를 사용하다가도 GraphQL로 변경하려 할 때 프레젠테이션 계층의 코드만 변경하고 서비스 계층은 변경하지 않아도 된다. 데이터 접근 계층은 데이터를 저장하고 관리하는 기술을 담당해 주고 그렇기에 JDBC, JPA와 같은 구체적인 데이터 접근 기술로부터 서비스 계층을 보호해 준다. 그 결과로, JDBC를 사용하다가 JPA로 변경하더라도 서비스 계층은 변경하지 않아도 된다. 왜냐하면 서비스 계층은 데이터 접근 계층에 직접 접근하는 게 아니라 데이터 접근 계층이 인터페이스를 제공하고 서비스 계층은 이 인터페이스에만 의존하면 되기 때문이다.

이로 인해 파생되는 긍정적인 부분은 유지보수가 수월해지고 테스트도 편리해진다.

이러한 이유로 인해 잘 만들어진 구조는 인터페이스와 그 인터페이스를 구현한 구현체가 나뉘는 것이고 사용자는 구현체가 어떤 식으로 구현했는지를 세세히 알 필요 없이 인터페이스를 가져다가 사용만 하면 되는 것이다. (예: DataSource 인터페이스와 이 인터페이스를 구현한 여러 가지 구현체(HikariDataSource, DriverManagerDataSource,...) 이것을 추상화라고 한다.

 

 

정리하자면..

구조에 정답이 있는 것은 아니지만, 더 나은 구조에 가까울수록 변경이 있을 때 변경에 대한 제약이 적다. 즉, 서비스 계층은 가급적 비즈니스 로직만 구현하고(순수 자바 코드로) 특정 구현 기술에 의존을 가급적 지양해야 한다. 그래야 이후 사용하는 기술을 변경하더라도 서비스 계층에 변경 영향 범위를 최소화할 수 있기 때문이다. 

 

서비스 계층에서 특정 기술에 의존하고 이 서비스 계층에 사용되는 비즈니스 로직이 별로 없으면 크게 문제가 될 것이 없지만, 만약 그 코드가 수만 줄 수십만 줄이라면 기술하나를 바꿨는데 수십만줄이 모두 변경되어야 한다. 그렇게 변경을 하면? 아주 매우 엄청 높은 확률로 사이드 이펙트가 발생할 것 같다..