Spring 서비스 추상화와 단일 책임 원칙

Spring의 Service에 대하여...

핵심 비즈니스 로직이 들어있는 계층이다.

비즈니스 로직은 UI와 데이터 저장 기술이 변경되도 최대한 변경없이 유지되어야 하기 때문에 가급적 특정 구현 기술에 의존하지 않고 순수하게 유지하는 것이 좋다.

데이터 액세스 계층에서 Checked Exception을 UnChecked Exception으로 바꾸는 이유가 여기있다.
Service에서는 특정 구현 기술에 의존하지 않아야 때문에 데이터 액세스 계층에서 발생하는 예외인 SQLException같은 Checked Exception이 Service 계층까지 넘어오는 것을 방지하는 것 입니다.

또한 Spring에서는 기본적으로 Uncheck Exception의 경우 트랜젝션을 rollback해주는 것을 Default값으로 설정 되어있으나 이는 설정을 통해 변경 가능합니다.
[ 체크 예외도 rollback한다던지 언체크 예외 중에서도 특정 예외는 rollback하지 않겠다 등 ]

---

서비스 추상화

서비스의 추상화는 언제나 일관된 방식의 기술로의 접근 환경을 제공하는 구조를 말하며 이는 Java의 특징 중 하나인 다형성을 이용한 것이다.

 

책에서는 예시로 DB 연결, 데이터 액세스, 트랜잭션 등을 바꿔도 서비스 계층의 소스 코드의 수정이 발생하지 않아도 된다는 것으로 설명되어 있다.

수직, 수평 계층구조와 의존관계

1. 수평적

Service계층과 Dao계층은 애플리케이션 계층으로 볼 수 있고 이를 각자가 맡은 책임으로 분리되어 있다고 볼 수 있습니다.

2. 수직적

TransactionManager는 Serivce 계층에서 트랜잭션이라는 기술을 사용하기 위해 의존하고 있는 추상화 계층이라고 보기 때문에 서로 수직적인 계층 구조를 가지고 있다고 볼 수 있습니다.

---

단일 책임 원칙

객체 지향 개발 5대 원리인 SOLID중 SRP(Single Responsibility Principle)의 관한 내용이다.

객체 지향 설계의 5원칙
SRP(Single Responsibiliy Principle)	단일 책임 원칙
OCP(Open Closed Principle)	개방 폐쇄 원칙
LSP(Listov Substitution Principle)	리스코프 치환 원칙
ISP(Interface Segregation Principle)	인터페이스 분리 원칙
DIP(Dependency Inversion Principle)	의존 역전 원칙

• 단일 책임 원칙 
  • 하나의 클래스(객체)는 단 하나의 책임만 가져야 한다.
• 개방 폐쇄 원칙
  • 기존 코드를 변경하지 않으면서 기능은 추가할 수 있지만(확장 or 개방) 수정은 할 수 없어야(폐쇄) 한다.
• 리스코프 치환 원칙
  • 하위 시스템은 상위 시스템의 타입으로 교체가 가능해야한다. 
• 인터페이스 분리 원칙
  • 인터페이스를 각각 기능(SRP)에 맞게 분리해야한다.
• 의존 역전 원칙 (결합도를 낮춘다.)
  • 대상의 추상화를 의존해야한다.

---

비즈니스 로직을 담당하는 계층( Service )과 데이터 액세스를 담당하는 계층 ( DAO )으로 나누는 것은 서로 다른 책임을 갖기 때문에 단일 책임 원칙을 잘 지켜서 설계했다고 볼 수 있습니다.

Service에서 시작하는 추상화 된 트랜잭션을 통해 수직적인 의존관계를 가지고 있습니다.

DAO에서는 DB에 접근하기 위해 추상화 된 DataSource와 수직적인 의존관계를 가지고 있습니다.

 

이런 의존 관계를 갖을 수 있는 이유는 Spring에서 지원하는 핵심적인 기능인 DI(Dependency Injection)이다.