애플리케이션 아키텍처

애플리케이션 아키텍처

이번 시간에는 애플리케이션 아키텍처를 어떤 식으로 구성할지 간단하게 소개를 해드리겠습니다.

먼저 우리가 일반적으로 하는 그 계층형 아키텍처라는 걸 사용할 건데요. 컨트롤러, 서비스, 리포지토리는 딱 이 구조로 갈 겁니다. 리포지토리에서에 데이터베이스 접근하고, 각각은 이제 저희가 엔티티나 Value Object들을 설계해 놓은 그런 도메인을 다 참조하도록 설계를 할 겁니다.

그래서 컨트롤러나 웹 계층이 있고, 그 다음에 핵심 비즈니스 로직과 트랜잭션을 처리하는 서비스 계층, 그리고 JPA를 직접 사용을 해서, 그러니까 엔티티 매니저 이런 걸 직접 사용해서 데이터베이스에 접근하고 처리를 하는 리포지토리 계층이 있고요. 그 다음에 도메인은 엔티티가 모여있는 계층이고, 모든 계층에서 이 도메인 계층을 사용할 수 있는 설계로 가져가겠습니다.

그래서 패키지 구조가 jpabook의 jpashop 밑에 domain, 공통 예외를 모아놓은 exception, repository, service, web 이런식으로 패키지 구조가 잡힐 겁니다. 추가로 나중에 api 정도 더 들어갈 수 있을 것 같아요.

그리고 참고로,

지금 그림에서는 그려놨는데, 여러분 컨트롤러에서 서비스만 호출할 수 있는 게 아니라 컨트롤러가 리포지토리에 바로 접근할 수도 있는 구조를 가져갈 겁니다.

그렇게 좀 유연하게 할 예정입니다. 대신에 방향은 단방향으로 흐르도록 가지고 갈 예정입니다. 간단한 조회할 때는 그냥 바로 컨트롤러에서 리포지토리에 가고, 간단한 회원정보를 하나 뿌릴 때는 그냥 회원 리포지토리에서 바로 회원을 찾아와서 출력하거나 그런 식으로 하겠다는 이야기입니다.

너무 딱딱하게 아키텍션을 가져가면 정말 단순하게 컨트롤러에서 리포지토리를 부르면 끝나는데 서비스는 단순하게 리포지토리 위임할 일 밖에 없는데, 모든 걸 다 서비스를 타야 되면 그것도 실용적인 관점에서는 좋지는 않거든요. 그래서 이렇게 진행을 할 예정입니다.

자 그리고 이제 개발 순서는 어떻게 할 거냐면, 먼저 여러분 이 서비스랑 리포지토리랑 이 도메인, 이 도메인은 우리가 다 거의 설계를 했죠? 그래서 이쪽 웹 환경(Controller, web)을 제외한 이 핵심 비즈니스 계층을 먼저 설계를 할 거고 개발을 할 겁니다. 그리고 서비스와 리포지토리를 개발한 다음에 테스트 케이스로 검증을 할 거예요. 그리고 나면 컨트롤러나 웹쪽은 이게 다 된 상태에서 그 다음에 들어갈 겁니다.

자 그래서 그 다음부터 진행할 목차를 대략적으로 말씀드리면 먼저 회원 도메인을 개발할 거고요. 여기서 회원 리포지토리, 회원 리포지토리를 jpa로 개발한다는 거죠. 그 다음 회원 서비스, 회원에 대한 비즈니스 로직들을 개발하고, 회원기능 테스트 할 거고, 똑같이 상품 도메인을 할 거고 주문 도메인도 똑같이 할 겁니다.

이렇게 해서 웹과 관련 없는 핵심 비즈니스 로직과 리포지토리를 먼저 다 개발을 할 거고요. 그 다음에 끝나고 나면 웹계층을 개발할 겁니다. 이거는 thymeleaf로 실제 저 화면들을 쭉 개발을 하는 거고요.

이게 끝나고 나면 마지막으로는 API, 요즘 API 개발이 너무 많이 필요하죠. 시스템들 연동할 때도 그렇고요. 그리고 싱글 AJAX 통신할 때도 필요하고, 안드로이드 아이폰 통신할 때도 필요하고요. 아무튼 등등. 요즘 거의 API 없이는 못살죠. 그래서 그 다음에는 API를 어떻게 개발하는지 쭉 설명을 해드리고, 여기서는 성능 최적화까지 보여드릴 겁니다.

그래서 이런 식으로 진행을 하겠습니다.