This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
sole discretion of GitLab Inc.
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@fabiopitino
| 2024-05-07 |
모듈식 모놀리식 ADR 001: 애플리케이션 도메인 모듈화
맥락
코드베이스를 모듈화하기 전에 우리는 먼저 어떻게 나눌지를 정의해야 했습니다.
결정
우리는 먼저 응용프로그램 도메인(백엔드 비즈니스 로직)에 중점을 두면서 모듈화의 범위 밖에 있는 응용프로그램 어댑터(Web 컨트롤러 및 뷰, REST/GraphQL 엔드포인트)를 초기에 제외합니다.
이에 대한 이유는 다음과 같습니다:
- 응용프로그램 어댑터의 코드는 항상 특정 도메인과 일치하지 않을 수 있습니다. 예를 들어: 프로젝트 설정 엔드포인트나 Merge Request 페이지에는 여러 도메인에 대한 참조가 포함됩니다.
- SaaS 아키텍처에서 메모리를 절약하기 위해 서로 다른 프로필을 사용하여 별도의 Rails 노드를 실행해야 했습니다. 예를 들어: SaaS에서는 전체 Rails 애플리케이션을 로드할 필요 없이 더 많은 Sidekiq 노드를 실행할 수 있기를 원했습니다. 우리의 가정은 Sidekiq를 실행하기 위해 ActionCable, REST 엔드포인트, GraphQL 뮤테이션 또는 Rails 뷰가 필요하지 않다는 것입니다. 우리는 응용프로그램 도메인 및 인프라 코드만 필요로 합니다. 이러한 가정은 Cells의 도입에도 여전히 유효할 수 있지만, 이러한 가정을 다시 평가해야 합니다.
- 범위와 노력을 작게 유지합니다. 도메인 코드만 다루는 것은 응용프로그램 어댑터 및 모든 케이스의 복잡성보다 이해하기 쉽습니다.
응용프로그램 어댑터의 범위를 제외하는 결정은 최종 결정이 아니며 나중에 다시 평가하기로 결정했습니다.
마지막으로, 기술적인 고려 사항을 포함하는 인프라 코드(일반적으로 lib/)는 각 도메인 모듈이 작동하기 위해 의존하는 공통 “플랫폼” 모듈의 일부가 될 것입니다.
“플랫폼” 모듈은 독립적인 라이브러리로 분리된 독립형 라이브러리로 분해될 수 있습니다.
결과
우리는 주로 비즈니스 로직을 모듈화함으로써 엔지니어들을 위한 규칙과 지침을 단순화합니다. 우리는 동일한 일련의 패턴을 모듈 전체에 적용할 수 있습니다.
대안
응용프로그램 어댑터를 모듈화 작업에 포함하는 것을 고려했지만 다음을 알아봤습니다:
- 어댑터를 모듈화하는 것은 더 섬세한 과정이며 라우트와 같은 사용자 지향 의존성을 보존해야 합니다.
- 어댑터 코드의 크기는 전체 응용프로그램 도메인보다 훨씬 작습니다.