만능 클래스는 분해의 걸림돌
애플리케이션 곳곳에 사용되는 만능 클래스17는 그 존재만으로도 분해의 걸림돌입니다. 이런 클래스에는 대부분 애플리케이션의 여러 측면에 관한 비즈니스 로직이 있는데, 굉장히 많은 필드가 다수의 컬럼을 가진 DB 테이블에 매핑된 경우가 많습니다. 이런 클래스는 거의 모든 애플리케이션에 하나쯤은 있죠. 가령 은행 시스템의 계좌, 전자 상거래 시스템의 주문, 보험사 시스템의 정책 등 주요 도메인과 연관된 클래스가 그렇습니다. 만능 클래스는 애플리케이션의 여러 측면의 상태/동작을 보이지 않게 감싸고 있기 때문에 이 클래스를 사용하는 전체 비즈니스 로직을 서비스로 분리하려면 골치가 아픕니다.
FTGO 애플리케이션의 Order 클래스도 만능 클래스입니다. 소비자가 주문한 음식을 배달하는 것이 이 애플리케이션의 목표이므로 거의 모든 시스템이 주문과 연관되어 있습니다. 단일 도메인 모델 체제라면 Order는 애플리케이션 곳곳의 상태/동작을 가리키는 아주 큰 클래스일 것입니다.
그림 2-10을 보면 주문 처리, 음식점 주문 관리, 배달, 지불에 해당하는 필드/메서드가 Order 클래스에 몰려 있습니다. 상태 모델도 적잖이 복잡합니다. 한 모델이 완전히 떨어져 있는 다른 애플리케이션 파트의 상태 전이까지 기술하고 있습니다. 이런 구조로는 코드를 여러 서비스로 나누려고 해도 이 클래스 하나 때문에 작업을 진행하기가 버겁습니다.
▲ 그림 2-10 만능 클래스 Order는 하는 일이 너무 많다