실무 에서 실용적인 아키텍처?

이 글을 쓰게된 이유

최근 사이드 프로젝트를  시작하면서 패키지 구조 부터 시작해서 모듈간의 분리로 인한 멀티 모듈 공부를 하다 아키텍처에 대해서 공부하다 궁금했던 헥사고날 아키텍처에 까지 공부를 하다보니 이 글 을 쓰게 되었다.

(제목은 어그로입니다 죄송합니다 ㅎㅎ;;)

실무에서의 헥사고날

일단 헥사고날의 간단한 후기는 정말 성숙한 도메인이 이며 프로젝트의 수명이 굉장히 길어질거라는 확신이 있지 않는 이상 실무에는 도입하기가 어려울것 같다 라는 생각이 지금은 든다.

(추가해야 할 코드의 양이 너무 많다)

 

굉장히 실용적으로 보이는 계층형 아키텍처

최근 애플리케이션 아키텍처에 대해서 자세히 공부를 하다보니 살짝 동일한 부분이 있는 아키텍처를 발견했다.

4 계층 레이어를 주로 사용하는 게 보인다.

 

https://xeounxzxu.medium.com/spring-4%EA%B3%84%EC%B8%B5%EB%A0%88%EC%9D%B4%EC%96%B4-

%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-8dc40298ba90

Spring | 4계층레이어 소프트웨어 아키텍처

https://techblog.tabling.co.kr/%ED%85%8C%EC%9D%B4%EB%B8%94%EB%A7%81-%EC%98%A4%ED%94%BC%EC%8A%A4%EC%9D%98-layered-architecture-72674e8ed1c6

테이블링 오피스의 Layered Architecture

 

지속 성장 가능한 소프트웨어를 만들어가는 방법. 스프링은 국내에서 정말 많이 쓰이고 있습니다, 개인적으로 많은 회사를… | by Gemini Kim | Medium

지속 성장 가능한 소프트웨어를 만들어가는 방법

 

 

 

위에 글들의 작성자 분들 모두 비슷한 이유 로 레이어를 하나 추가 해서 사용하고 계신 것 같다.

 

이유는 서비스 레이어가 너무 비대해지면서 책임지는게 많아 지는 것이다

 

이렇게 분리 함으로 서 얻는 장점은

상세 구현을 분리함으로써 서비스 레이어 에서 코드 상 으로 비즈니스 로직을 파악하기가 굉장히 좋다.

(파사드 패턴)

 

예를 들자면 주문 로직이라면 상품 재고 조회와 차감 후 주문 등록을 해야 할 것이다.

그렇다면 상품과 주문의 상세 구현을 따로 다른 책임으로 바라 볼 것인데 이것을 

하나의 레이어를 추가해 그 레이어의 책임으로 분리를 하는 것이다.

 

DDD에서 말하는 도메인레이어 와 비슷한 역할인 것 같다.

예를 들어 하나의 서비스 레이어 에서 도메인 객체에게 메소드를 실행시켜 값을 가져오는 것과

하나의 큰 행동을 아래 레이어로 분리시켜 각 도메인끼리의 행동을 조합해 필요한 데이터만 가공해 반환해주는 행동이다.

 

 

재 사용성도 증가한다.

예를 들자면  A service에서 B service를 DI해서 가져와서 사용 한다면 필요한 데이터를 받지만 B Service 를

기존에 사용하던 Controller에 맞게 응답하는  DTO 값을 반환한다.

 

즉 내가 원하는 것은 그 비즈니스 로직을 처리한 것의 결과 객체 이지 그 서비스가 사용후 컨트롤러 레이어에서 사용하는 DTO 객체를 원하는 것이 아니다.

이것은 컴포넌트의 재사용성을 현저히 낮게 하는 방식 인 것이다.

 

그렇다면 이 서비스의 구현을 상세구현 레이어로 옮긴 후 그 도메인 으로 반환을 한다면 재 사용성이 굉장히

올라갈 것 이다.

 

 

Implement (상세 구현)  레이어 추가 

Implement 의 레이어의 위치는 : Business Layer 와  Persistence Layer 사이에 위치한다.

Implement  레이어의 역할은 좀 더 구체 적인 구현 로직을 수행하며 풍부한 도메인 모델(Rich Domain Model)이라면 각 객체에게 필요한 기능을 호출과 검증을 하고 데이터가 필요하면 Persistence Layer을 의존해

원하는 값을 받는다.

 

장점

가장 큰 장점은 비즈니스 레이어의 가독성이 굉장히 좋아짐 과 동시에 책임이 줄어 드는 것이다.

변환된 DTO 객체가 아니라 Business Layer에서 원하는 순수 도메인(엔티티)를 반환받는 레이어가 추가된것이 레이어의 재사용성이 굉장히 올라갔다는 것이 이 레이어의 가장 큰 장점이다.

이건 장점이자 단점 ? 레이어가 추가되었기에 단위테스트를 수행할 레이어도 증가 했다는 소리다. 테스트코드를 조금 더 꼼꼼하게 테스트를 할수 있다.

단점

 공수가 많이 든다 확실히 레이어가 추가되었다 는 건 작성해야할 (테스트)코드의 증가와 관리해야 할 레이어도 증가 한다는 소리다.

  Response DTO 가공이 필요하지 않은 로직도 불필요한 계층 흐름을 타게 된다.

 즉 싱크홀 안티패턴 : 레이어에서 추가적인 작업 없이 그저 전달만 하는 경우를 뜻한다.

 

 

음 토이 프로젝트에서 적용을 해 볼 생각이다. 나중에 프로젝트 시작 시 팀원들에게 아키텍처에 대해서 설명 후 좋다고 생각을 하면 도입을 해도 좋을 것 같고 단순하고 실용적인 좋은 아키텍처 라고 생각이 든다.