| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@fabiopitino
| 2024-05-07 |
모듈화된 모놀리식 ADR 002: 경계가 정의된 컨텍스트
컨텍스트
주로 응용 프로그램 도메인에 중점을 두었으므로 이를 모듈화하는 방법을 정의해야 했습니다.
결정
응용 프로그램 도메인은 GitLab 응용 프로그램의 최상위 모듈을 정의하는 경계가 정의된 컨텍스트로 나뉩니다. ‘경계가 정의된 컨텍스트’라는 용어는 도메인 주도 설계에서 널리 사용됩니다.
경계가 정의된 컨텍스트를 정의하는 것은 조직 구조가 아닌 제품 구조를 중심으로 코드를 구성하는 것을 의미합니다.
Proposal: split GitLab monolith into components의 연구 결과, 제품 범주를 기준으로 따르는 것이 조직 구조를 폴더 구조로 변환하는 것보다 훨씬 나을 것으로 보입니다. (예: app/modules/verify/pipeline-execution/...)
그러나 이러한 가이드만으로는 충분하지 않으며 보다 구체적인 전략이 필요합니다.
- 경계가 정의된 컨텍스트(최상위 모듈)는 충분히 심층적이어야 하며 구현 세부 정보를 캡슐화하고 더 작은 인터페이스를 제공해야 합니다.
- 일부 제품 범주인 ‘브라우저 성능 테스트’와 같은 경우, 고유의 경계가 정의된 컨텍스트를 나타내기에는 너무 작습니다. 그렇기에 이러한 경우에는 합리적인 경우에 제품 범주를 함께 그룹화하는 전략이 필요합니다.
- 제품 범주가 깨끗한 경계로 변환되지 않을 수도 있습니다.
카테고리: 파이프라인 구성과카테고리: 지속적 통합은 파이프라인 작성 팀과 파이프라인 실행 팀이 많은 코드를 공유하는 예시입니다. - 코드 일부가 명확한 제품 범주와 관련되어 있지 않을 수도 있습니다.
위와 같은 사항을 감안해 제품 범주는 응용 프로그램에서 활동 중인 경계가 정의된 컨텍스트의 대략적인 개관을 제공합니다. 따라서 제품 범주를 사용하여 초기 경계가 정의된 컨텍스트 집합을 정하고 관련된 또는 강력하게 결합된 범주를 같은 경계가 정의된 컨텍스트 아래 그룹화하고 누락된 경우 새로운 경계가 정의된 컨텍스트를 만듭니다.
결과
2024년 5월에, 본 페이지에서 설명한 모듈화의 첫 번째 단계를 완료한 경계가 정의된 컨텍스트 작업 그룹을 완료했습니다.
우리는 코드의 경계가 정의된 컨텍스트 디렉터리을 정의하고 RuboCop을 사용하여 이를 강제화하기 시작했으며, 완전히 네임스페이스화된 모놀리식로 이동하기 위해 팀 멤버들은 명시적으로 경계가 정의된 컨텍스트를 생성하고 삭제함으로써이 디렉터리을 편집할 수 있으며, 이 결정은 Staff+ 엔지니어들에 의해 검토됩니다.
대안
코드를 조직 구조에 맞추는지를 평가했으나 실행가능하지 않다고 결정했습니다.
- 제품 범주는 소유권을 변경할 수 있으며 상당히 빈번한 변화가 있음을 목격했습니다. 제품 범주가 소유권이 변경될 때마다 코드를 옮기면 유지 관리 부담이 너무 커집니다.
- 팀 및 조직 변경은 특정 모듈의 소유권을 다시 라벨링하는 것으로 충분해야 합니다.
- 결합 및 복잡성은 비즈니스 로직 및 제품 구조와 직접적으로 관련되어 있습니다. 조직 구조에 부합하는 코드 구조는 불필요한 복잡성과 더 많은 결합을 생성할 수 있습니다.