소프트웨어 설계 가이드

GitLab 코드베이스에서 유비쿼터스 언어 사용, 경계 컨텍스트 정의, 전지전능 클래스 제어, 유스케이스 중심 설계 등 소프트웨어 설계 원칙을 설명합니다.

CRUD 용어 대신 유비쿼터스 언어 사용 # 코드는 제품과 사용자 문서에서 사용하는 것과 동일한 유비쿼터스 언어 를 사용해야 합니다. 유비쿼터스 언어를 올바르게 사용하지 않으면, 지속적인 번역이나 여러 용어의 사용으로 인해 기여자와 고객 모두에게 큰 혼란을 초래할 수 있습니다. 이는 또한 커뮤니케이션 전략 에도 위배됩니다. 아래 예시에서 CRUD 용어는 모호함을 유발합니다. 이름만 보면 epic_issues 연관 레코드를 생성하는 것처럼 보이지만, 실제로는 기존 이슈를 에픽에 추가하는 작업입니다. Rails 관례에서 비롯된 epic_issues 라는 이름은 서비스 객체와 같은 상위 추상화 계층으로 누수됩니다. 코드가 유비쿼터스 언어가 아닌 프레임워크 전용 용어로 표현되고 있습니다. # Bad EpicIssues::CreateService 유비쿼터스 언어를 사용하면 코드가 명확해지고, 프레임워크 용어를 해석하려는 독자에게 인지적 부담을 주지 않습니다. # Good Epic::AddExistingIssueService 프로젝트 생성처럼 모호하지 않고 단순한 개념을 표현하거나, 기존 유비쿼터스 언어와 일치하는 경우에는 CRUD를 사용할 수 있습니다. # OK: Matches the product language. Projects::CreateService 새 클래스와 데이터베이스 테이블은 유비쿼터스 언어를 사용해야 합니다. 이 경우 모델 이름과 테이블 이름은 Rails 관례를 따릅니다. 유비쿼터스 언어를 따르지 않는 기존 클래스는 가능하다면 이름을 변경해야 합니다. 데이터베이스 테이블과 같은 일부 저수준 추상화는 이름을 변경할 필요가 없습니다. 예를 들어, 모델 이름이 테이블 이름과 다를 경우 self.table_name= 을 사용하세요. 이름 변경이 어려운 경우에만 예외를 허용할 수 있습니다. 예를 들어, 해당 이름이 STI에 사용되거나, 사용자에게 노출되거나, 변경 시 호환성이 깨지는 경우입니다. 경계 컨텍스트 # 경계 컨텍스트의 목표, 동기 및 방향에 대한 자세한 내용은 경계 컨텍스트 워킹 그룹 및 GitLab 모듈형 모놀리스 설계 문서 를 참고하세요. 네임스페이스를 사용하여 경계 컨텍스트 정의하기 # 건강한 애플리케이션은 작동하는 경계 컨텍스트를 나타내는 매크로 및 하위 컴포넌트로 분리됩니다. GitLab 코드에는 매우 많은 기능과 컴포넌트가 있어, 관련된 컨텍스트를 파악하기 어렵습니다. 이러한 컴포넌트는 비즈니스 도메인 또는 인프라 코드와 관련될 수 있습니다. 모든 클래스는 해당 클래스가 동작하는 컨텍스트를 나타내는 모듈/네임스페이스 내에 정의되어야 합니다. 이러한 컨텍스트를 정의하기 위해 허용된 네임스페이스 목록 을 관리하고 있습니다. 클래스를 도메인별로 네임스페이스로 묶으면: 도메인이 의미를 명확히 해주므로 유사한 용어 간의 모호함이 해소됩니다. 예를 들어, MergeRequests::Diff 와 Notes::Diff 처럼 구분됩니다. 최상위 네임스페이스는 도메인 전문가로 식별된 하나 이상의 그룹과 연계될 수 있습니다. 컴포넌트