모놀리식 아키텍처(MA) VS 마이크로 서비스 아키텍(MSA)
모놀리식 아키텍처
모놀리식 아키텍처는 애플리케이션이 하나의 아키텍처로 구성된 경우를 말한다. (즉 모듈 하나에 애플리케이션 서비스에 필요한 모든 코드가 담겨져 있다.)
장점
1. 하나의 아키텍처로 구성되어 당장 개발이 필요한 소규모 프로젝트에 용이하다
2. 개발, 테스트에 용이하다
단점
1. 일부 오류로 인해 전체 서비스가 중지될 수 있다
2. 유지보수가 어렵다
3. 작은 수정사항이 있어도 전체를 다시 빌드하고 배포해야한다
마이크로 서비스 아키텍처
마이크로 서비스 아키텍처는 애플리케이션이 여러개의 아키텍처로 구성된 경우를 말한다.서비스가 점점 커지면서 시스템이 무거워지는 모놀리식 아키텍처의 단점을 보완하고자 나온 아키텍처이다.모듈마다 자체 DB를 가지고 있다.
장점
1. 서비스별 시스템이 독립적이라 유지보수에 용이하다2. 상대적으로 빌드, 배포가 빠르다
단점
1. 코드가 분산되어 모니터링하기 어렵다2. 다양한 통신에서 발생하는 오류가 잦다3. 통합 테스트가 어렵다.4. 메서드만 호출하면 되는 모놀리식과 달리, 다른 모듈의 서비스가 필요할 경우 http 통신을 통해서 호출해야 한다.
<정리>
서비스의 확장 가능성이 낮고, 시스템이 작다 => 모놀리식서비스의 확장 가능성이 높고, 시스템이 크다 => MSA
DAO, DTO, VO
DAO (Data Access Object)
- 실제 DB에 접근하기 위한 객체
- DB의 데이터에 접근하여 CRUD를 수행한다
- Repository와 유사하다
DTO (Data Transfer Object)
- 계층 간 데이터 교을 하기 위해 사용하는 객체
- 로직이 들어있지 않고, 단순 getter / setter 만 가진 객체(Java Beans)
- DB에서 데이터를 얻은 후, Service 혹은 Controller로 보낼 때 사
VO (Value Object)
- 단순히 데이터 값을 전달하기 위한 용도로 사용되는 객체 (DTO와 유사)
- 도메인 주도 설계에서 이야기하는 값 객체 (DTO와 차이가 있음)
- 위 두가지 의미를 가지고 있음
- DTO와 달리 Read-Only라 setter가 없고(값 수정 불가능), getter 외 다른 로직을 가질 수 있다
Repository, Domain
Repository
- DAO와 유사함
- DAO와 차이점이라면, Repository는 엔티티 객체를 보관하고 관리하는 저장소, DAO는 데이터 접근을 위한 DB접근 관련 로직을 모아둔 객체
- 실제 개발에선 비슷한 의미로 사용함
Domain(entity)
- 도메인은 여러가지 의미가 있지만 주로 프로젝트 디렉토리 구조상 Domain은 엔티티를 의미한다.
- 엔티티는 실제 DB와 매핑되는 객체를 의미한다.
- 해결하고자 하는 문제의 영역 = Domain (사전적 의미)
=> SW 개발자 입장에서는 요구 사항 영역으로 볼 수 있다. (ex : 쇼핑물을 만든다 가정하에 결제, 상품, 회원, 게시글, 댓글 등등이 도메인에 해당)
Controller, Service
Controller
- MVC 디자인 패턴에서 사용
- 클라이언트의 요청(Request)를 어떻게 처리할지 결정하는 파트
=> 예를 들면 클라이언트가 특정 URL에 접근을 요청하면 어떻게 처리해서 응답할지 결정해주는게 Controller다
MVC에 대한 설명은 여기서 조금 다룬다
Service
- 클라이언트의 요청(Request)에 대해 어떤 처리를 해야할지 결정하는 파트
- 컨트롤러가 받은 요청에 대해 알맞은 데이터(정보)를 가공해서 다시 컨트롤러에게 준다.
(데이터를 가공하는 과정을 비즈니스 로직을 수행한다고 한다.)
<정리>
1. 클라이언트 요청 => Controller 호출
2. Controller => Service 호출
3. 비즈니스 로직 작동
4. Service => Controller 호출
5. Controller => 클라이언트 응답