비즈니스 규칙 검증과 입력 유효성 검증

[xxeol2]

항상 미션에서마다 고민하던 일..
입력 유효성 검증(구문상의 유효성), 비즈니스 규칙 검증(의미적인 유효성)간의 경계가 무엇일까요? (p.45)
책에서는 입력 유효성 검증은 유즈케이스 로직의 일부가 아니라고 한다.
그러면 입력 유효성 검증에서는 비즈니스 규칙에 대한 검증은 이루어지면 안되는것일까?

[xxeol2]

테오: 정말 원칙적으로 생각을 하면, 입력 유효성 검증은 데이터 내용은 상관 없이 데이터 자체가 유효한지를 검증하는 것이라 생각한다. 비즈니스 영역에서는 비즈니스 규칙이나 도메인 규칙을 검증하는게 맞다고 생각한다. 이번 리뷰에서, 카프카네 회사에서는 입력단에 검증을 다 몰아주고 도메인에서는 검증을 하지 않는다고 한다. 예전에 우아한 객체지향볼때도 이런걸 들었었는데, 검증로직을 한 곳에 몰으면 테스트하기 쉬워지고 성능상에서는 이점을 가진다. (잘못된 정보가 도메인 영역까지 들어오지 않기 때문에) 성능이나 테스트 용이성을 고려하기 위해서 입력단에서 처리를 하고 도메인은 순수한 엔티티로 남겨둔다고 한다. 그래서 내 결론은, 원칙적으로는 안하는게 맞고 관심사만 검증하는게 맞지만, 성능이나 보안이 관련된 부분이면 입력 유효성검증과 비즈니스 유효성 검증이 함께 이루어질 수 있다고 생각한다.
비버: 입력 단에서 비즈니스 규칙을 알아야하는게 아닌가?
all: ㅇㅇ.
테오: 알았을 때 생기는 문제가 뭐냐?생각해보면, 도메인 규칙이 변했는데 입력단의 로직이 바뀐다는 것이다. 근데 바뀌는 부분이 검증부분밖에 없으니까 눈 감고 넘어가주자.
애쉬: 도메인 규칙 (이름 3자, 5자) 상수같은건 어디서 선언하냐?
테오: static 클래스 열고 거기 때려박을 것 같다. 패키지 위치는 입력단에.
누누: 멀티모듈로 했을 때 순환참조때문에 컴파일이 안된다. (한 개라도 참조하는 순간 컴파일이 안된다.) 도메인측에 있어야한다. (의존성 방향이 단방향이기 때문에)
애쉬: "도메인 클래스 내 상수 public" vs "static 클래스"
무민: 도메인 상태에 접근 해야하나 안해야하나로 나뉠 것 같다. 예를들면, 비즈니스 규칙 검증과 같은 경우 책에서 출금 계좌는 초과 출금을 하면 안되기때문에 비즈니스 규칙일 것 같고, 입력 유효성같은 경우 이런 상태에 관계없는 경우일 것 같다. (30000원이 0원 이상인 값인지)
애쉬: 닉네임 정할때 3자 - 10자 이건 입력측에서 검증하고, 중복방지는 비즈니스에서 검증하고? 이런식 ?