https://github.com/woowacourse/java-racingcar/pull/295
사용자로부터 입력받은 값은 어디에서 검증하는 것이 좋을까?
자바 어플리케이션에는 외부에서 받아온 값이든, DB 에서 조회해온 값이든 데이터를 객체 로 감싸서 로직을 수행한다. 데이터가 감싸진 객체 내에서 값을 더하거나 뺄 수도 있고 또 다른 객체와의 상호작용을 하기도 한다. 비즈니스 로직을 수행하기 위해서 어플리케이션에서 사용하는 객체는 올바른 데이터를 보유하고 있는 객체여야 한다. input 과 validator 객체도 편의에 따라 검증 로직을 위치시킬 수는 있으나, 더욱 안전한 어플리케이션을 개발하기 위해서는 객체의 생성자에서 검증하는 것이 적절하다.
또한 검증 이라는 것도 어떤 값을 검증하느냐에 따라 분류될 수 있다. 비즈니스 로직을 기준으로, 검증하려는 로직이 비즈니스 로직과 밀접하게 연관이 있으면 객체의 생성자에서 검증하고, 그렇지 않으면 다른 위치에서 검증한다. 예를 들어, null 또는 빈값에 대한 검증을 어디에 두어야 할까? 관점에 따라서 null 또는 빈값은 비즈니스 로직이 될 수도 있고 그렇지 않을 수도 있다. DB 제약조건을 기준으로 생각한다면 null 과 빈값은 비즈니스 로직이 될 수 있다. DB 기준을 제외한 서비스 자체에 대해서 생각한다면 비즈니스 로직이 되지 않을 수도 있다.
자바 어플리케이션이 아닌 웹 어플리케이션을 개발한다고 가정한다면, 사용자로부터 받아오는 값은 API 의 입력값이 된다. 개인적으로 이러한 입력값에서 선택적으로 입력할 수 있는 값이 아님에도 null 또는 빈값이 들어온다면 이는 잘못된 요청으로 인식하여 객체의 생성자가 아닌 DTO 에서 검증한다.
자바는 객체지향적인 언어이다. 객체지향이란 데이터를 가지고 있는 객체가 수행하려는 기능에 대한 책임을 가지는 방법이다. 객체가 가지고 있는 데이터를 getter 를 이용하여 꺼내고, 이를 다른 객체에서 사용한다면 객체지향적 프로그래밍과는 거리가 멀게 된다. 그럼 왜 객체지향 프로그래밍을 해야 할까? 객체지향 프로그래밍을 하기 위해서 객체에게 역할(기능)을 부여한다. 객체가 가지고 있는 데이터를 꺼내서, 외부에서 필요한 대로 활용하는 것이 아닌 역할을 담당하고 있는 객체에게 기능을 수행하도록 요청한다. 결국 데이터를 꺼내지 않고 객체에게 책임을 넘기는 것은 기능의 성격에 따라 한곳으로 묶는 역할을 한다. 데이터가 아닌 객체간의 관계를 기준으로 설계한다면, 중복적인 로직을 한 곳에 모으는 것과 동시에 서비스에 대한 구조를 파악하기 쉬워진다.
도메인 객체는 서비스에 대한 비즈니스 로직을 수행하고, 뷰는 사용자에게 보여지는 부분을 담당한다. 사용자에게 보여주고 싶은 정보는 상황에 따라서 언제든지 변경될 수 있다. 서비스를 확장하면서 한 화면에 보여지는 데이터를 추가/변경한다고 해서 서비스의 핵심인 비즈니스 로직이 쉽게 변경되면 안된다. 사용자에게 보여지는 데이터를 담당하는 부분과 순수 데이터를 관리하는 비즈니스 로직을 적절하게 분리하는 것이 변경점을 줄여주어 유지보수성을 높여준다.
여러 미션을 진행하면서 나만의 상수화의 기준에 대해 정리해보았다.
재사용성
동일한 의미를 가지고 있는 데이터가 여러 곳에 위치해있으면, 비즈니스 로직이 변경되었을 때 모든 데이터가 변경이 적용되었는지 알기 어렵다. 이를 방지하기 위해 두번이상 사용하는 값에 대해서 상수화를 한다.
비즈니스적 의미
개발하고 있는 서비스에서 의미가 있는 값이면 상수화를 한다. 비즈니스 로직을 담고 있다는 것은 결국 비즈니스 상황에 따라 언제든지 변경이 될 가능성이 높다는 의미를 가진다. 변화에 빠르게 대응하기 위해, 또 서비스에서 어떤 의미를 가지는지를 나타내기 위해 상수화를 한다.
값 자체가 의미를 나타내는 경우 상수화를 하지 않음
사용하는 값 자체가 의미를 바로 나타내는 경우가 있다. 문자열, 특히 에러 메시지의 에러 문구는 작성한 문자열 그대로의 의미를 나타낸다. 이러한 경우 오히려 상수화를 하여 부여한 이름이 더 헷갈리는 경우가 발생할 수도 있다.