[Spring] 토비 스프링 - 스프링 프로젝트 시작하기

posted by donghyun

2 min read

태그
spring tobi

애플리케이션 아키텍처

계층형 아키텍처

3계층 아키텍처와 수직 계층

  1. 데이터 액세스 계층

    Dao와 JdbcTemplate

  2. 서비스 계층

구조로 보자면 가장 단순하다. 잘 만들어진 스프링 애플리케이션의 서비스 계층 클래스는 이상적인 POJO로 작성된다. POJO로 만든다면 객체지향적인 설계 기법이 적용된 코드를 통해서 비즈니스 로직의 핵심을 잘 담아내고, 이르 쉽게 테스트하고 유연하게 확장할수 있다.

  1. 프레젠테이션 계층

데이터 중심 아키텍처

SQL로 거의 모든 로직을 짜고, 자바는 그냥 인터페이스 도구로 전락

사용자가 수정한 정보는 다시 맵이나 배열 등에 담겨서 전달될 것이다. DB 수정 작업을 담당하는 DAO는 이렇게 전달되는 데이터의 구조를 알고 있어야 할 것이다. DAO가 만드는 SQL의 결과에 모든 계층의 코드가 의존하게 된다.

오브젝트 중심 아키텍처

​ 가장 큰 특징은 도메인 모델을 반영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는데 사용한다는 것.

​ DB에서 가져온 데이터를 도메인 오브젝트 구조에 맞게 변환해줘야한다. 한 번 변환되면 그 이후 작업은 수월.

도메인 오브젝트 사용의 문제점

​ 최적화된 SQL을 매번 만들어 사용하는 경우에 비해 성능 면에서 조금 손해를 감수. 오브젝트의 빈 필드들. Prouct 오브젝트에 딸려오는 Category 오브젝트 - 낭비.

​ 지연된 로딩(lazy loading) : 최소한의 오브젝트 정보만 읽어두고 관계하고 있는 오브젝트가 필요한 경우에만 다이나믹하게 DB에서 다시 읽어오기.

빈약한anemic 도메인 오브젝트 방식

​ 도메인 오브젝트에 정보만 담겨 있고, 정보를 활용하는 아무런 기능도 갖고 있지 않다면 이는 빈약한 도메인 오브젝트. 3개 계층에 독립적으로 존재하면서 일관된 구조의 정보를 담아서 계층 간에 전달하는데 사용

풍성한 도메인 오브젝트 방식

​ 풍성한(rich)혹은 영리한(smart) 도메인 오브젝트 방식은 빈약한 도메인 오브젝트 방식의 단점을 극복하고 객체지향적인 특징을 잘 사용할 수 있도록 개선한 것.

​ 어떤 비즈니스 로직은 특정 도메인 오브젝트나 그 관련 오브젝트가 가진 정보와 깊은 관계가 있다. 이런 로직을 서비스 계층의 코드가 아니라 도메인 오브젝트에 넣어주고, 서비스 계층의 비즈니스 로직에서 재사용하게 만드는 것.

​ 이렇게 도메인 오브젝트 안에 로직을 담아두면 이 로직을 서비스 계층의 메소드에 따로 만드는 것보다 응집도가 높다. 데이터와 그것을 사용하는 기능이 한곳에 모여 있기 때문이다. ~한 서비스에서 다른 서비스 클래스를 DI 해줄 필요 없이 바로 도메인 오브젝트로 로직 실행가능

도메인 오브젝트는 DAO를 DI 받을 수 없다. 빈이 아니기 때문이다!

스프링의 빈으로 관리되는 3계층의 오브젝트들은 도메인 오브젝트를 자유롭게 이용할 수 있지만 그 반대는 안된다.

도메인 계층 방식

도메인 오브젝트가 스스로 필요한 정보를 DAO를 통해 가져오고 변경도 하고… 또한 다양한 기반계층의 서비스를 이용하도록 할수 없을까? 해서 도메인 계층의 역할과 비중이 확대된방식.

  1. 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행

  2. 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용. DI를 설정해주자.

    스프링이 관리하지 않는 도메인 오브젝트에 DI 적용 위해선 AOP가 필요. 스프링 AOP 대신 AspectJ AOP 사용하면 클래스의 생성자가 호출되면서 오브젝트가 만들어지는 시점을 조인 포인트로 사용 가능. 일반 오브젝트에도 AOP 부가기능 적용 가능. 특별한 부가기능 적용 - DI 가능한 대상을 스프링 컨테이너에서 찾아 DI해주기

  3. 서비스 계층의 역할은 인터페이스 역할

DTO

도메인 오브젝트가 도메인 계층 밖으로 전달 될 때 별도로 복사되어 넘겨지는 오브젝트