Meraki는 애플리케이션의 복잡성을 줄이고 테스트 용이성을 높이기 위해 코드베이스를 모듈화하고, 모놀리스 내부에 명확한 경계를 설정하여 팀의 자율성과 책임감을 강화하는 전략을 채택했습니다. 이 접근 방식은 주로 컨트롤러, 뷰(ERB), 모델에 흩어져 있던 비즈니스 로직을 Plain Old Ruby Object(PORO)로 추출하는 데 중점을 둡니다.
비즈니스 로직 추출 및 모듈화
- 컨트롤러에서 추출: 대규모 컨트롤러 액션 내의 비즈니스 로직을 더 작은 객체로 분리했습니다. 이는 컨트롤러 테스트의 복잡성을 줄이고 비즈니스 로직에 대한 높은 테스트 커버리지의 투자 수익률을 극대화하기 위함입니다. 예시로, 다중 커피 머신 설정 업데이트 로직을
UpdateWaterTankSettings및UpdateCoffeeMachineSettings와 같은 전용 클래스로 분리하여 컨트롤러는 HTTP 요청 처리와 응답 생성에만 집중하도록 했습니다. - 뷰(ERB)에서 추출: ERB 파일 내의 비즈니스 로직은 코드 품질 도구로 분석하기 어렵고 테스트가 까다로웠습니다. 이를 PORO로 대체하여 코드 가독성을 높이고 테스트 용이성 및 코드 품질 측정을 가능하게 했습니다. 예를 들어, 커피 머신 설정 속성을 렌더링하는 로직을
CoffeeMachineConfiguration클래스로 옮겨 뷰는 데이터 표현에만 집중하도록 했습니다. - 모델에서 추출: ‘Fat Model’이라는 기존의 베스트 프랙티스와 달리, 모델에 집중된 비즈니스 로직은 코드 응집도를 낮추고 암묵적 결합을 유발하여 ‘잡동사니 서랍’처럼 변질될 수 있습니다. 이를 해결하기 위해 모델의 특정 메서드 로직을
CoffeeMachineBroadcastDetails와 같은 별도 클래스로 추출하여 모델의 책임을 분리하고 테스트 용이성 및 확장성을 확보했습니다.
도메인 경계 설정 및 네임스페이스 도입
추출된 비즈니스 로직 객체들은 domain/coffee_machine과 같은 도메인 기반 디렉토리 구조로 이동되어 네임스페이스를 형성합니다. 이는 엔지니어들이 전체 400만 라인의 코드베이스를 알 필요 없이 자신의 팀이 소유한 코드에 집중할 수 있도록 인지 부하를 줄여줍니다. 또한, 이 도메인 경계는 팀이 조직 전체의 합의 없이도 자신들의 코드를 개선하고 다양한 접근 방식을 실험할 수 있는 자율성을 부여하며, 동시에 해당 코드에 대한 책임감을 강화합니다. 도메인 내부의 코드 조직 방식(예: 서브도메인 또는 패턴 기반)은 팀의 자율에 맡겨 유연성을 확보했습니다.