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 2023-06-21

Bounded Context 정의

역사적 맥락

2024년 5월까지 GitLab 코드베이스는 명확한 도메인 구조가 없었습니다. 일부 모듈의 생성을 강제로 유도했지만 이를 일관되게 수행하기 위한 명확한 전략이 없었습니다.

대부분의 코드는 제대로 네임스페이스화되거나 조직화되지 않았습니다.

  • Ruby 네임스페이스는 항상 Single Source of Truth(SSoT)를 나타내지 않았습니다. 중복되는 개념이 여러 네임스페이스에 걸쳐 퍼져 있었습니다. 예를 들어, Abuse::와 Spam:: 또는 Security::Orchestration::과 Security::SecurityOrchestration.
  • 동일한 Bounded Context에 관련된 도메인 코드가 여러 디렉터리에 흩어져 있었습니다.
  • lib/ 디렉터리에 있던 도메인 코드가 app/에서 여러 네임스페이스와 다른 위치에 존재했습니다.
  • 일부 네임스페이스는 매우 얕았는데, 몇 개의 클래스만 포함하고 다른 네임스페이스는 매우 깊고 크기가 컸습니다.
  • 이전 코드의 많은 부분이 네임스페이스화되지 않아 사용된 컨텍스트를 이해하기 어렵게 만들었습니다.

2024년 5월에 Bounded Context를 정의하고 강제로 시행했습니다.

목표

  1. Bounded Context가 가져야 하는 특성들의 디렉터리을 정의합니다. 예: 적어도 1가지 상품 카테고리와 관련이 있어야 함.
  2. 모든 도메인 코드가 분해되는 최상위 Bounded Context 디렉터리을 소유합니다.
  3. 엔지니어들이 사용 가능한 Bounded Context 디렉터리을 명확하게 볼 수 있고 새로운 클래스와 모듈을 추가할 위치를 쉽게 결정할 수 있습니다.
  4. 애플리케이션에 새로운 Bounded Context를 추가하는 프로세스를 정의합니다. 이는 드물게 발생해야 하며 새로운 Bounded Context는 이전에 정의된 특성을 준수해야 합니다.
  5. 새로운 최상위 네임스페이스 이외의 인가된 것을 사용하지 못하도록 Bounded Context 디렉터리을 강제합니다.

반복

  1. lib/ 디렉터리에서 라이브러리 추출하기.
    • 이 단계는 모듈화에 대한 차단 않지만 lib/에 존재하는 일반적이지 않은 코드가 적을수록 Bounded Context를 식별하고 분리하기 쉬워집니다.
    • 도메인 코드에 의존하는 것을 방지하기 위해 별도의 프로젝트에서 살 수 있는 코드를 격리합니다.
  2. ADR-001: 애플리케이션 도메인 모듈화 시작하기
  3. ADR-002: 기능 카테고리를 중심으로 Bounded Context 정의하여 코드에서 SSoT로 설정
  4. ADR-003: 모든 모듈과 라이브러리에 담당자 지정
  5. Bounded Context 디렉터리을 게시.
    • Bounded Context의 SSoT 디렉터리 정의
    • RuboCop 정적 분석기를 사용하여 강제
    • 주어진 디렉터리을 기반으로 표준이 아닌 Rails 디렉터리를 autoload.