디렉토리 구조와 Facade 패턴

1. 디렉토리 구조

 

Spring을 통한 Backend의 프로젝트나 Frontend의 React를 사용한 프로젝트를 만들거나

어떤 프로젝트를 만들 때도 개발자는 항상 디렉토리 구조를 잘 생각하고 설정해야 한다.

프론트엔드 입장에서 디렉토리 구조를 짤 때 깊은 생각을 해보지는 않았지만,

React를 사용해서 한번이라도 SPA를 만들어 본 입장에서 이 블로그의 내용이 참 좋아보였다.

https://velog.io/@teo/separation-of-concerns-of-frontend

프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)

 

디렉토리 구조가 중요한 이유는 프로젝트를 내가 잘 알아볼 수 있도록 정리해야하기 때문일 뿐만 아니라,

동료 개발자의 입장에서도 중요하기 때문이다.

 

잘 만들어둔 디렉토리 구조는 동료들의 작업 생산성에도 좋은 영향을 줄 것이고,

내가 알아보기도 힘든 디렉토리 구조를 가진 프로젝트는 동료들에게 안 좋은 DX를 선사할 것이다.

 

"개발자는 항상 두 종류의 client를 상대한다. 외부의 user와 내부의 동료 개발자들이다."

 

그렇기 때문에 디렉토리 구조는 팀별로 컨벤션을 지켜서 만들어두는 것이 좋고, 관련 토의는 건설적이라고 생각한다.

 

필자는 Spring을 사용한 Backend 프로젝트를 진행하기 때문에, Spring에서 디렉토리 구조를 설명하자면

크게 두 가지로 나뉘어진다.

 

2. Spring 사용 시 디렉토리 구조 (1) 3-Layered Architecture 기반

• controller
  • advisor
  • user
  • payment
  • cart
  • delivery
• service
  • user
  • payment
  • cart
  • delivery
• repository
  • ...
• configuration, exception, util, dto, entity 등

이러한 방식의 장점은 응집력이 낮다는 것을 잘 이용할 수가 있다는 것이다.

가령, Service를 구성하는데 있어서 해당 서비스가 user서비스와 cart의 정보가 필요하다면

이 두 개를 조합한 facade 서비스를 구성해서 사용할 수 있고, 디렉토리의 추가가 매우 자유로워
디렉토리 수준에서의 OCP를 구현할 수 있다고 생각한다.

 

단점은 수많은 domain에 대해서 한 눈에 정리되지는 않는 디렉토리 구조라고 생각된다.

자유로운 만큼 정리 될 만큼 파악하기는 쉽지 않다는 것이다.

 

3. Spring 사용 시 디렉토리 구조 (2) Domain 기반 

• user
  • controller
  • service
  • repository
• payment
  • ...
• cart
  • ...
• delivery
  • ...

이러한 방식의 장점은 3-Layered Architecture 기반 디렉토리와 반대로,
단일 Controller-Service-Repository간 응집력이 높을 때 잘 드러난다.

각각의 도메인에 대해서 필요한 것들이 딱딱 묶여져 정리되어 있기에,

단일 서비스들을 다룰 때는 상당히 유용한 방식이라고 생각된다.

마찬가지로, 단일 서비스가 추가될 때도 유용할 것이다.

 

다만 단점은 여러 서비스를 복합해서 사용할 때 드러날 것으로 생각된다.

이 경우에, 디렉토리를 어떻게 해야할 지 감이 잘 오지 않는다는 것이다.

또한 접근제어자를 통한 캡슐화 과정에서 접근제어자를 잘못 설정했을때 발생할 수 있는
추가적인 유지 보수내역도 생길 것으로 예상한다.

 

 

 

4. Facade 패턴

앞서 2번에서 여러 서비스를 합쳐 facade를 만들어서 사용하기에 용이하다고 했는데, 

Facade란 무엇일까? 이를 정리해보겠다.

Facade 패턴이란, 객체지향 프로그래밍을 위한 디자인 패턴 중 하나로
여러 기능을 묶어 하나의 기능으로 통합, 재정의하는데 사용하는 구조(Structural)패턴이다.  

Facade 패턴은 여러 복잡한 서브 시스템을 단일 진입점(혹은 인터페이스)으로 추상화하여 제공하는 구조 패턴이다.

 

위의 설명에서 여러 서비스를 묶어 하나의 Facade 서비스를 만든다고 했으므로, 이 예시를 한 번 써보겠다.

@Service
@RequiredArgsConstructor
public class PointService{
    private final PointRepository pointRepository;
    ...
}

 

@Service
@RequiredArgsConstructor
public class CardService{
    private final CardRepository cardRepository;
    ...
}

 

 

위처럼 두 개의 cash와 card service가 있다고 할 때, PaymentFacadeService를 다음과 같이 만들 수 있다.

@Service
@RequiredArgsConstructor
public class PaymentFacadeService {
    private final PointService pointService;
    private final CardService cardService;
    ...
}

 

이렇게 할 경우, PaymentFacadeService는 두 개의 서비스를 이용한 복합 로직을 가진 서비스를 제공할 수 있게 된다.

가령, 포인트가 있는 경우 포인트를 사용하고 남은 결제를 카드로 진행하는 지불 방식을 구현하는 것과 같이 말이다.

 

 

5. @Slf4j 어노테이션에서 facade의 의미

spring boot에서 log를 통한 관리를 필요로 할 때, @Slf4j라는 어노테이션을 이용해왔다.이때 Slf4j란 Simple Logging Facade for Java의 줄임말인데, 그들의 홈페이지에서 아래와 같이 소개한다.

"The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time." https://www.slf4j.org/index.html

 

logging으로 사용되는 각각의 API들을 facade로 통합하거나, abstraction을 제공하는 방식으로 사용된다.로깅에 logging, logback, log4j, 와 같은 Framework를 사용할텐데 어떤 구현체를 사용하든 상관없이항상 동일한 방식으로 로그를 사용할 수 있도록 해주는 library이다.Spring boot는 기본적으로 logback을 log Framework로 사용하는데,

private static final Logger logger = LoggerFactory.getLogger(MyService.class);
  logger.info("This is an info message");
  logger.debug("This is a debug message");
  logger.error("This is an error message");

원래는 위와 같이 사용하지만, 
@Slf4j를 통해서 굳이 Logger클래스와 LoggerFactory의 구현이 없이도 log.info, log.error의 꼴로 통합해서 사용하게 된다.

 

각각의 구현체에 대해 어떻게 적용하는지를 보여주는 다이어그램은 아래와 같다.자세히 보면 알겠지만, adaptation layer, 즉 adapter 패턴 또한 사용이 되었지만 이 글에서는 소개하지 않겠다.간략히 말하자면 여러 로깅 프레임워크들을 감싸서 확장해 사용할 수 있도록 할 때 사용된 것이다.

 

 

 

https://en.wikipedia.org/wiki/Facade_pattern

Facade pattern - Wikipedia