계층화된 모듈식 아키텍처로 순환 종속성 제거

모듈식 설계는 모든 대규모 애플리케이션에서 매우 중요합니다. 애플리케이션 도메인을 분리하는 데 도움이 되고 개발자가 특정 도메인에만 집중할 수 있으며 온보딩 프로세스가 훨씬 쉬워집니다. 또한 모놀리스를 마이크로서비스로 분할하기로 결정하면 덜 고통스러울 것입니다.

모듈식 설계의 기본 아이디어는 유형 대신 목적에 따라 프로젝트 파일을 구성하는 것입니다.

앱을 모듈화하는 과정에서 직면하게 될 가장 일반적인 문제 중 하나는 모듈 간의 순환 종속성의 함정입니다. 순환 종속성은 종종 세 번째 모듈을 추출하거나 두 모듈을 병합해야 함을 나타내는 지표입니다.

그러나 그것들을 구성하는 방법은 무엇입니까?

계층화된 모듈

나는 개인적으로 내가 작업한 모든 프로젝트에서 순환 종속성 문제에 직면했습니다.

한번은 모듈 간의 순환 종속성의 근원을 찾기 위해 내 앱 중 하나의 구조를 진단하던 중 모듈이 특정 계층까지만 독립적으로 작동할 수 있음을 깨달았습니다.

이 구체적인 예에서 문제는 API 계층이었습니다(앱은 백엔드 서비스였습니다). 최종적으로 작업을 수행하고 프런트 엔드 개발자에게 결과를 출력하기 위해 여러 모듈에서 정보를 집계해야 했습니다.

그래서 다음과 같이 프로젝트 구조를 변경하기로 결정했습니다.



이에:



그리고 리팩토링 프로세스가 완료된 후 더 이상 내 모듈 간에 순환 종속성이 없었습니다. 또한 모듈 계층 구조가 이해하기 훨씬 더 쉬웠습니다.

보시다시피 이 구조는 계층화된 아키텍처와 모듈식 설계의 조합입니다. 자신의 필요에 맞게 이를 개인화할 수 있습니다.

지금 내 모듈을 어떻게 구성합니까?

현재 모듈을 3가지 주요 범주로 분류합니다.

/src
  /db-modules
  /feature-modules
  /api-modules

DB 모듈

도메인과 관련된 데이터베이스 모델을 독립적으로 관리하고 검증할 수 있습니다

.

기능 모듈

도메인과 관련된 데이터베이스 모델을 독립적으로 관리하고 검증할 수 있습니다

.

독립적으로 로직을 구현하고 비즈니스 작업을 수행합니다

.

DB 모듈에서 가져올 수 있음

API 모듈

도메인과 관련된 데이터베이스 모델을 독립적으로 관리하고 검증할 수 있습니다

.

독립적으로 로직을 구현하고 비즈니스 작업을 수행합니다

.

API 인터페이스를 구현하고 API 요청을 독립적으로 처리합니다(다른 API 모듈에 의존하지 않음)

.

DB 모듈에서 가져올 수 있음

기능 모듈에서 가져올 수 있음

기본적으로 모듈이 자신의 문제를 처리할 수 있는 정도에 따라 모듈 유형이 결정됩니다. 또한 복잡성이 증가함에 따라 더 많은 그룹을 도입할 수 있습니다(예: 집계 모듈 그룹을 추가하여 마이크로 서비스 및 외부 API를 처리하는 데 유용한 여러 API 모듈을 통합할 수 있음).

이 아키텍처에 대해 어떻게 생각하십니까? 아래에 댓글을 남겨주세요