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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @fabiopitino 2023-06-21

Bounded contexts 정의하기

현황

현재 GitLab 코드베이스에는 명확한 도메인 구조가 없습니다. 첫 번째 단계로 일부 모듈을 생성하기 위한 압박을 가했지만, 일관되게 수행할 명확한 전략이 없습니다.

대부분의 코드는 적절하게 네임스페이스 지정되어 있지 않고 조직화되어 있지 않습니다:

  • 사용된 Ruby 네임스페이스가 항상 SSoT(단일 원천 판독)을 나타내지 않습니다. 중복되는 개념이 여러 네임스페이스에 걸쳐 퍼져 있습니다. 예: Abuse::Spam:: 또는 Security::Orchestration::Security::SecurityOrchestration.
  • 동일한 bounded context와 관련된 도메인 코드가 여러 디렉토리에 흩어져 있습니다.
  • 도메인 코드가 lib/ 디렉토리에 존재하며, 해당 도메인 코드가 app/ 내에서와는 다른 네임스페이스에 있습니다.
  • 일부 네임스페이스는 매우 얕아서 몇 개의 클래스만 포함하고 있는 반면, 다른 네임스페이스는 매우 깊고 큽니다.
  • 오래된 코드 중 많은 부분이 네임스페이스가 지정되어 있지 않아 사용된 문맥을 이해하기 어렵게 만듭니다.

목표

  1. Bounded contexts가 가져야 할 특성 목록을 정의합니다. 예: 적어도 1개의 제품 범주와 관련이 있어야 함.
  2. 모든 도메인 코드가 분해된 최상위 bounded contexts의 목록을 보유합니다.
  3. 엔지니어들이 사용 가능한 bounded contexts 목록을 명확하게 볼 수 있으며 새 클래스와 모듈을 추가할 위치를 쉽게 결정할 수 있습니다.
  4. 새로운 bounded context를 애플리케이션에 추가하는 프로세스를 정의합니다. 이는 꽤 드물게 발생해야 하며 새로운 bounded context는 이전에 정의된 특성을 준수해야 합니다.
  5. 권한이 부여된 것 외에 새로운 최상위 네임스페이스를 사용할 수 없도록 bounded contexts 목록을 강제합니다.

이터레이션

0. 코드베이스에서 라이브러리 추출

2023년 6월, 우리는 메인 코드베이스에서 젬을 `monorepo 내의 ‘gems/’ 디렉토리로 추출을 시작했습니다.

이것은 모듈화로 나아가는 첫 번째 단계입니다.

  • 일반적인 코드와 도메인 코드(비즈니스 로직을 제공하는 코드)를 분리하고자 합니다.
  • lib/ 디렉토리에서 일반적인 코드를 정리하고자 합니다.
  • 별도의 프로젝트에 존재할 수 있는 코드를 격리시켜 도메인 코드에 의존하지 않도록 하려 합니다.

이러한 젬은 여전히 monorepo의 일부이지만 필요한 경우 별도의 저장소로 추출할 수 있습니다.

젬 추출은 모듈화에 방해되지 않지만 lib/에 일반적인 코드가 적을수록 bounded context를 식별하고 분리하기 쉬워집니다.

1. Bounded context를 정하는 것은 무엇인가요?

Proposal: split GitLab monolith into components에서의 연구를 통해 제품 범주들을 가이드로 따르는 것이 조직 구조를 폴더 구조로 변환시키는 것보다 훨씬 나을 것으로 보입니다.

그러나 이러한 가이드만으로 충분하지 않으며 보다 구체적인 전략이 필요합니다: - 제품 범주는 소유권이 변경될 수 있으며 몇몇의 빈번한 변화를 보았습니다. 제품 범주가 변경될 때마다 코드를 이동하는 것은 유지 보수에 너무 많은 부담을 주게 됩니다. - 팀과 조직 변경은 특정 모듈의 소유권을 다시 라벨링하는 것으로 처리해야 합니다. - bounded context(최상위 모듈)는 구현 세부 정보를 묘사하고 작은 인터페이스를 제공하기 위한 충분히 깊어야 합니다. - 브라우저 성능 테스트와 같은 일부 제품 범주는 단독으로 bounded context를 표현하기에는 너무 작습니다. 의미가 있는 경우 제품 범주를 함께 그룹화하는 전략이 있어야 합니다. - 제품 범주가 반드시 깨끗한 경계로 변환되는 것은 아닙니다. Category:Pipeline CompositionCategory:Continuous Integration는 파이프라인 작성 팀과 파이프라인 실행 팀이 많은 코드를 공유하는 몇 가지 예시입니다. - 코드 일부는 명확한 제품 범주와 연결되어 있지 않을 수 있습니다.

위와 같은 이유로 제품 범주는 애플리케이션 내에서 사용되는 bounded contexts의 대략적인 개요를 제공합니다.

한 가지 아이디어는 제품 범주를 사용하여 초기 bounded contexts의 집합을 스케치하는 것입니다. 그런 다음, 관련된 또는 강하게 결합된 범주를 동일한 bounded context 아래로 그룹화하고 누락된 경우 새로운 bounded contexts를 생성하는 것입니다.

2. 기존 bounded contexts 식별

스프레드시트에 있는 모든 Ruby 파일을 나열하고 위의 가이드라인을 따라 구성 요소로 분류합니다. 일부 파일은 이미 매우 명확합니다(예: Ci::, Packages:: 등). 구성 요소는 이미 있는 네이밍 가이드를 따라야 합니다.

이것은 각 DevOps 단계의 대표 멤버(예: 시니어 엔지니어)가 참여하는 짧은 생명주기를 가진 작업 그룹일 수 있습니다. 이 WG는 고수준의 구성 요소를 정의하는 데 도움을 주고, 해당 DevOps 단계에서의 변경 사항을 주도하기 위한 DRI(직접적 책임을 지는 사람)를 담당할 것입니다.

3. 바운디드 컨텍스트 목록 게시

코드베이스에서 추출된 바운디드 컨텍스트(최상위 네임스페이스) 목록은 정적으로 정의되어 프로그램적으로 사용할 수 있어야 합니다.

# file: config/bounded_contexts.yml
bounded_contexts:
  continuous_integration:
    dir: modules/ci
    namespace: 'Ci::'
  packages: ...
  merge_requests: ...
  git: ...

이 정적인 목록으로 우리는 다음을 할 수 있습니다:

  • 엔지니어들이 전체 그림을 볼 수 있도록 기존의 바운디드 컨텍스트를 문서화합니다.
  • 새로운 클래스와 모듈을 배치할 위치를 이해합니다.
  • 목록에 없는 최상위 네임스페이스가 사용되지는 않는지 강제로 확인합니다.
  • 주어진 목록을 기반으로 표준이 아닌 Rails 디렉터리를 자동으로로드합니다.