[CH11] 자주 쓰는 서버 구조와 설계 패턴

 

MVC 패턴

 

• Model : 비즈니스 로직 처리
• View: 사용자가 보게 될 결과를 생성하여 전달 (HTML, 타임리프, json ... )
• Controller: 사용자의 요청을 해석하여 모델을 실행, 뷰를 선택하여 사용자에게 응답 제공

 

 

계층형 아키텍처

 

계층형 아키텍처란?

 

• 계층1 > 계층 2 > 계층 3 ...
• 계층마다 특정 역할을 수행하고 하위 계층에 의존
• 상위 계층은 하위 계층에 의존할 수 있지만, 하위 계층은 상위 계층에 의존 불가
• 계층이 밑의 하위 계층에만 의존하도록 강제할 수 있고, 건너의 하위 계층까지 의존하도록 허용할 수도 있음

 

 

웹 애플리케이션에서의 4계층

 

• 표현(UI) 계층: 사용자와의 상호작용을 담당 (컨트롤러, 뷰의 역할)
• 응용 계층: 모델 계층과 인프라계층을 사용하여 필요한 기능을 구현하고 표현 계층에 리턴(주로 서비스의 역할)
• 도메인(모델) 계층: 도메인 로직 구현
• 인프라(영속) 계층: DB 연동, 문자 발송과 같은 구현 기술 지원 (DAO)

 

흩어지는 도메인 로직

 

• 도메인 계층 구현에 미숙한 개발자들이 많음
• 도메인 계층을 빼고 표현(컨트롤러) > 응용(서비스) > 인프라(DAO) 와 같이 3계층으로 구현하는 케이스 나잖아?
• 3계층으로 구현하는 경우 도메인 로직이 응용, 인프라 계층으로 분산되는 경향이 있어 유지보수가 어려워짐

 

예를 들어, 쿼리를 다음과 같이 작성하면

update member set status = 20 where member_id = ? and status = 10

 

 

서비스 단? 에서는 다음과 같이 코드를 작성하게 되는데, 도메인 로직이 없어 어떤 조건일 때 status가 변경되는지 확인이 어려움

int cnt = mado.updateMemberStatus(id);
if (cnt == 0) {
	// 변경 건이 없으므로 에러 처리
}

 

⚠️ 도메인 로직이 다른 계층에 흩어지는 것을 방지하려면 DDD 패턴 등을 활용하여 도메인 로직을 한 곳으로 모으는 것이 중요

 

 

DDD와 전술 패턴

 

도메인 모델 구성요소

 

• 엔티티 (Order와 같이 식별자로 구분되는 객체)
• 밸류 (금액, 주소와 같은 불변의 값)
• 애그리거트 (Order 엔티티, OrderLine 밸류 집합, ShoppingAddress 밸류와 같이 관련된 객체를 묶은 개념적인 단위)
• 리포지토리 (물리적 저장소와 연결하는 모델)
• 도메인서비스 (특정 애그리거트에 속하지 않은 로직을 구현한 서비스)
• 도메인 이벤트 (도메인 내에서 발생한 이벤트로, 다른 부분에 변화를 알리는 역할 수행)

 

도메인서비스 구현 예시

 

1) 레포지토리로 DB에 접근

2) Order 객체가 애그리거트 루트 역할을 하면서 해당 객체 내에서 cancel(도메인 로직) 처리

 

public class CancelOrderService {
    private OrderRepository orderRepository;

    @Transational
    public void cancel(OrderNumber orderNum) {
		Optional<Order> orderOpt = orderRepository.findId(orderNum);
		Order order = orderOpt.orElseThrow(() -> new NoOrderException());
		order.cancel();
    }
}

 

 

마이크로서비스 아키텍처

 

모놀리식 아키텍처

 

• 하나의 애플리케이션에 모든 것을 구현하는 방식
• 장점: 배포가 단순하고 테스트와 디버깅이 쉬움
• 단점: 작은 변경에도 전체 배포가 필요하며 한 기능의 문제가 전체에 영향을 줄 수 있음, 구현 기술 변경에 어려움 존재

 

 

마이크로서비스 아키텍처

 

• 서비스를 작은 단위로 분리하고 연동되도록 구현하는 방식
• 장점: 지속적인 배포가 용이, 기술에 대한 유연성 확보
• 단점: 테스트와 디버깅이 어렵고 모놀리식 대비 인프라가 복잡함

이벤트 기반 아키텍처

 

• 이벤트: 과거에 발생한 사건(ex. 주문 완료, 주문 취소, 인증 실패 등)
• 이벤트 생산자가 이벤트 브로커에 이벤트를 전달하고 브로커가 해당 이벤트에 관심있는 소비자에게 전달
• ex. 회원 인증 실패가 반복적으로 발생 ➡️ 이상 감지 시스템에 '인증 실패' 이벤트 전송, 비정상 접근 여부 파악
• ex. 주문 완료 이벤트 발생 ➡️ 배송 시스템에 주문 정보와 이벤트 전송, 배송 시작
• 이벤트 브로커는 카프카와 같은 메세징 기술 사용

 

 

CQRS 패턴(Command Query Responsibility Segregation)

데이터 변경(명령)과 데이터 조회 시 사용하는 데이터에 차이가 있음에도 불구하고 두 기능을 하나의 모델로 구현한다면 복잡성이 증가하고 유지보수가 어려워질 수 있기 때문에 명령을 위한 모델과 조회를 위한 모델을 분리하는 패턴

조회 모델을 별도로 구현할 경우 조회 모델에만 캐시를 적용하거나 조회 전용 DB를 사용하여 성능 향상 가능

음... 근데 내 생각은 별도의 DB를 사용하면 또 조회/명령 간의 DB를 동기화 시키기도 해야 하고... 비슷한 코드가 양방향으로 있으면 나중에 다른 사람이 유지보수할 때 어려워져서 나는 그냥 통합해서 구현하는게 좋은 것 같다